Ciddi bir proje üzerinde çalışıyorum. Ve sadece 2 ay veri modelleme üzerinde kendimi yetiştirdikten sonra kodlamaya başlayacam. Veri tabanı kesinleşti gibi FireBird.
Merak ettiğim bir kaç şey var.
1-En iyi performansı almak için tek kullanıcı bir vt modellemeyi ayrı cok kullanıcı bir vt modelleme ayrı mı yapsam yada kullanıcı ayırımının vt ile bir bağlı olmasamı diye düşünüyorum.
2-Tekrar eden bilgileri smalint (kod_id)bir degiskene atayıp sadece select lemi ceksem yada firebirdin yapısı guclu oldugu için ilgili yerlere tekrar bunları yazsam performans acısından degisen bir sey olurmu.
yani Söyle bir sey olsa Cari_Kod , Cari_isim, Adres,Kod_ID alalarını oldugu bir cari kart bir table olsa. Fatura dosyasında Cari_Kod, Cari_isim,Fatura_Tarihi, v.s bilgileri olsa. iyi bir modellemede iki alternatif var.
Cari_Kod='00001'
Cari_isim='Ahmet Sorsecer'
Adres=' istiklal caddesi '
Kod_ID='Gen_ID('Cari_Kod') olsun yani her bir yeni kayıtta bir smalint bir sayı üretilse
Fatura Dosyasında Sadece Kod_Id yi kullansam yani cari_kod,cari_isim ve adres alanlarını kaldırsam ve bütün raporlarda select ile Cari kart dosyasına bağlantı kurup where kod_id ile Cari_kod ve Cari_isim ve Adresi Ceksem Vt tarafıda doğru bir modelleme olucak amma evet amma direk fatura dosyasına kod_id yerine cari_kod ve cari_isim tekrar yazsam raporlamalarda kat kat hız kazanıyorum cunku örnek bir rapor cari_kod aralığı istenince kod_id li bir modllemede yavas lama oluyor diğerinde direk between kullanılabiliniyor.
Bu arada primary key cari_kod tabiki,
profesyonelce bir vt nasıl olmalı
3-View le yapılan bir seyi sp ile yapmaktansa view i kullanmak daha mantıklı geliyor baa
3. Foreign key lemi yoksa trigerlamı ikincil bağlantıları yapmak mantıklı.
4- işte en önemlisi bir fatura programı düşünelim delphi turkiye semineride de gördüm. Stok giriş cıkısları veya cari giris cikislari ayrı bir table la yazılıyor genelde de boyle olur ama bece fatura tableside bunnlar varken bir daha baska bir table ye bu harketleri yazmak anlamlı gelimiyor bana, sadece raporlamada hız kazadırıyor o kadar. Bu performansı tek bir fatura dosyasından cekmek diger kart table larla select edip join le birleştirirken kazanmak mümkün değilmi?
Tesekkür ederim
Veritabanı Modelleme
-
Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
Sana açıklayıcı güzel bir mesaj yazmıştım ama netin azizliğine uğradı..
yazdıklarımı ilk defa clipborda copyalamadan send etmiştim..
zaman bulursam tekrar yazarım..
yazdıklarımı ilk defa clipborda copyalamadan send etmiştim..
zaman bulursam tekrar yazarım..
Firebird Foundation Member #208
http://www.firebirdsql.org
http://www.firebirdsql.org
-
Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
>>
Ciddi bir proje üzerinde çalışıyorum. Ve sadece 2 ay veri modelleme üzerinde kendimi yetiştirdikten sonra kodlamaya başlayacam. Veri tabanı kesinleşti gibi FireBird.
>>
Doğru metod, doğru seçim.
Hele bizimki gibi harala gürele kod yazarak projeye başlanan bir ülkede.
Adamlar 1 sistem analisti ve mimarına 3 kuruş vermek istemez ama,
karadüzen yazılışmış bir projeyi yaşatmak için bir sürü yamayıcı programcıyı yıllarca beslerler. her alandaki uydurukluğumuz teknolojide de hakim.
>>
Merak ettiğim bir kaç şey var.
1-En iyi performansı almak için tek kullanıcı bir vt modellemeyi ayrı cok kullanıcı bir vt modelleme ayrı mı yapsam yada kullanıcı ayırımının vt ile bir bağlı olmasamı diye düşünüyorum.
>>
Tek kullanıcı, tek task gibi kavram kalmadı! bunu haala görememiş olman
hayret verici. artık cep telefonları bile multitasking yapıyor. Oyun oynarken bluetoothla belleğinde gezersin mesela..
Bir kullanıcı bile olsa, artık herkes çoklu işlem yapıyor. yani senin uygulamanı iki ayrı pencereden ya da subsystemden çalıştırmak isteyebilir. Tek kullanıcılı yaklaşımları unut. Bi adama %50 fazla performans sağlamak için ayrı bir kod ve DB yaratmak büyük cesaret.
>>
2-Tekrar eden bilgileri smalint (kod_id)bir degiskene atayıp sadece select lemi ceksem yada firebirdin yapısı guclu oldugu için ilgili yerlere tekrar bunları yazsam performans acısından degisen bir sey olurmu.
yani Söyle bir sey olsa Cari_Kod , Cari_isim, Adres,Kod_ID alalarını oldugu bir cari kart bir table olsa. Fatura dosyasında Cari_Kod, Cari_isim,Fatura_Tarihi, v.s bilgileri olsa. iyi bir modellemede iki alternatif var.
Cari_Kod='00001'
Cari_isim='Ahmet Sorsecer'
Adres=' istiklal caddesi '
Kod_ID='Gen_ID('Cari_Kod') olsun yani her bir yeni kayıtta bir smalint bir sayı üretilse
Fatura Dosyasında Sadece Kod_Id yi kullansam yani cari_kod,cari_isim ve adres alanlarını kaldırsam ve bütün raporlarda select ile Cari kart dosyasına bağlantı kurup where kod_id ile Cari_kod ve Cari_isim ve Adresi Ceksem Vt tarafıda doğru bir modelleme olucak amma evet amma direk fatura dosyasına kod_id yerine cari_kod ve cari_isim tekrar yazsam raporlamalarda kat kat hız kazanıyorum cunku örnek bir rapor cari_kod aralığı istenince kod_id li bir modllemede yavas lama oluyor diğerinde direk between kullanılabiliniyor.
Bu arada primary key cari_kod tabiki,
profesyonelce bir vt nasıl olmalı
>>
Ne demek istediğini tam anlamadım ama,
veritiplerini doğru seç. smallintin yettiği bi sahayı integer yapmanın kimseye faydası yok, sisteme hem işlem hem kapasite yükü olur sadece.
indexlemeler konusunda korkma. FB indexleri ön kısımlarından itibaren
tekrar edenleri elimine edip tek bir kere kaydeden özel bir mimariye sahip. compressed bitmap binary tree index kullanır.
FBv2 ve sonrası için Foreign keylerden de korkma. sistem bütünlüğü ve
tutarlılığı için bu şart. triggerla olmaz o iş. triggerlar transactionla yalıtımlıdır. index sistemi ise engine içinde bir denetime sahiptir.
>>
3-View le yapılan bir seyi sp ile yapmaktansa view i kullanmak daha mantıklı geliyor baa
3. Foreign key lemi yoksa trigerlamı ikincil bağlantıları yapmak mantıklı.
>>
View=SP değildir, ve renk olsun diye var değillerdir. hangisi ne zaman ne şekilde kullanılmalı, bunu uzmanlığın güçlendikçe anlarsın.
>>
4- işte en önemlisi bir fatura programı düşünelim delphi turkiye semineride de gördüm. Stok giriş cıkısları veya cari giris cikislari ayrı bir table la yazılıyor genelde de boyle olur ama bece fatura tableside bunnlar varken bir daha baska bir table ye bu harketleri yazmak anlamlı gelimiyor bana, sadece raporlamada hız kazadırıyor o kadar. Bu performansı tek bir fatura dosyasından cekmek diger kart table larla select edip join le birleştirirken kazanmak mümkün değilmi?
>>
RDBMS in anlamı objeleri ayrı tutup ilişkisel kullanmaktır.
hepsini bi yerde tutmak yer veya hız tasarrufu sağlamaz. ve ayrıca lock,conflict ve deadlock ihtimallerini artırır.
önce iyilerinden database fundementals& design tarzı kitapları anlayarak oku. yoksa koduna hakim değil kodların kölesi olursun.
Kolay gelsin.
Not:
ülen neredeyse bütün projeni bize yaptıracan ha musti!
projen bitip çok para kazanınca forumdakilere pasta-gazoz ısmarlamassan
bi daha yardım yok sana!
Ciddi bir proje üzerinde çalışıyorum. Ve sadece 2 ay veri modelleme üzerinde kendimi yetiştirdikten sonra kodlamaya başlayacam. Veri tabanı kesinleşti gibi FireBird.
>>
Doğru metod, doğru seçim.
Hele bizimki gibi harala gürele kod yazarak projeye başlanan bir ülkede.
Adamlar 1 sistem analisti ve mimarına 3 kuruş vermek istemez ama,
karadüzen yazılışmış bir projeyi yaşatmak için bir sürü yamayıcı programcıyı yıllarca beslerler. her alandaki uydurukluğumuz teknolojide de hakim.
>>
Merak ettiğim bir kaç şey var.
1-En iyi performansı almak için tek kullanıcı bir vt modellemeyi ayrı cok kullanıcı bir vt modelleme ayrı mı yapsam yada kullanıcı ayırımının vt ile bir bağlı olmasamı diye düşünüyorum.
>>
Tek kullanıcı, tek task gibi kavram kalmadı! bunu haala görememiş olman
hayret verici. artık cep telefonları bile multitasking yapıyor. Oyun oynarken bluetoothla belleğinde gezersin mesela..
Bir kullanıcı bile olsa, artık herkes çoklu işlem yapıyor. yani senin uygulamanı iki ayrı pencereden ya da subsystemden çalıştırmak isteyebilir. Tek kullanıcılı yaklaşımları unut. Bi adama %50 fazla performans sağlamak için ayrı bir kod ve DB yaratmak büyük cesaret.
>>
2-Tekrar eden bilgileri smalint (kod_id)bir degiskene atayıp sadece select lemi ceksem yada firebirdin yapısı guclu oldugu için ilgili yerlere tekrar bunları yazsam performans acısından degisen bir sey olurmu.
yani Söyle bir sey olsa Cari_Kod , Cari_isim, Adres,Kod_ID alalarını oldugu bir cari kart bir table olsa. Fatura dosyasında Cari_Kod, Cari_isim,Fatura_Tarihi, v.s bilgileri olsa. iyi bir modellemede iki alternatif var.
Cari_Kod='00001'
Cari_isim='Ahmet Sorsecer'
Adres=' istiklal caddesi '
Kod_ID='Gen_ID('Cari_Kod') olsun yani her bir yeni kayıtta bir smalint bir sayı üretilse
Fatura Dosyasında Sadece Kod_Id yi kullansam yani cari_kod,cari_isim ve adres alanlarını kaldırsam ve bütün raporlarda select ile Cari kart dosyasına bağlantı kurup where kod_id ile Cari_kod ve Cari_isim ve Adresi Ceksem Vt tarafıda doğru bir modelleme olucak amma evet amma direk fatura dosyasına kod_id yerine cari_kod ve cari_isim tekrar yazsam raporlamalarda kat kat hız kazanıyorum cunku örnek bir rapor cari_kod aralığı istenince kod_id li bir modllemede yavas lama oluyor diğerinde direk between kullanılabiliniyor.
Bu arada primary key cari_kod tabiki,
profesyonelce bir vt nasıl olmalı
>>
Ne demek istediğini tam anlamadım ama,
veritiplerini doğru seç. smallintin yettiği bi sahayı integer yapmanın kimseye faydası yok, sisteme hem işlem hem kapasite yükü olur sadece.
indexlemeler konusunda korkma. FB indexleri ön kısımlarından itibaren
tekrar edenleri elimine edip tek bir kere kaydeden özel bir mimariye sahip. compressed bitmap binary tree index kullanır.
FBv2 ve sonrası için Foreign keylerden de korkma. sistem bütünlüğü ve
tutarlılığı için bu şart. triggerla olmaz o iş. triggerlar transactionla yalıtımlıdır. index sistemi ise engine içinde bir denetime sahiptir.
>>
3-View le yapılan bir seyi sp ile yapmaktansa view i kullanmak daha mantıklı geliyor baa
3. Foreign key lemi yoksa trigerlamı ikincil bağlantıları yapmak mantıklı.
>>
View=SP değildir, ve renk olsun diye var değillerdir. hangisi ne zaman ne şekilde kullanılmalı, bunu uzmanlığın güçlendikçe anlarsın.
>>
4- işte en önemlisi bir fatura programı düşünelim delphi turkiye semineride de gördüm. Stok giriş cıkısları veya cari giris cikislari ayrı bir table la yazılıyor genelde de boyle olur ama bece fatura tableside bunnlar varken bir daha baska bir table ye bu harketleri yazmak anlamlı gelimiyor bana, sadece raporlamada hız kazadırıyor o kadar. Bu performansı tek bir fatura dosyasından cekmek diger kart table larla select edip join le birleştirirken kazanmak mümkün değilmi?
>>
RDBMS in anlamı objeleri ayrı tutup ilişkisel kullanmaktır.
hepsini bi yerde tutmak yer veya hız tasarrufu sağlamaz. ve ayrıca lock,conflict ve deadlock ihtimallerini artırır.
önce iyilerinden database fundementals& design tarzı kitapları anlayarak oku. yoksa koduna hakim değil kodların kölesi olursun.
Kolay gelsin.
Not:
ülen neredeyse bütün projeni bize yaptıracan ha musti!
projen bitip çok para kazanınca forumdakilere pasta-gazoz ısmarlamassan
bi daha yardım yok sana!
Firebird Foundation Member #208
http://www.firebirdsql.org
http://www.firebirdsql.org
Abi basım üstüne sorun yok. Bu proje üçretsiz sadece parası olmayan daha doğrusu ödeneği olmayan doğudaki bir yer için yapıalacak bir proje hatta para almak bi tarafa para vermemiz gereken bir proje.
Carikart dosyamızda
Cari_Kod='MM AB 00001'
Cari_isim='Ahmet Sorsecer'
Adres=' istiklal caddesi '
Cari_Kod='MM AB 00002'
Cari_isim='Mehmet Gecici'
Adres=' Vatan Caddesi '
...
...
...
Cari_Kod='ZZ ZZ 90002'
Cari_isim='Oktay Veli'
Adres=' serenler mahallesi '
bilgileri var.
Fatura keserken
Fatura_NO ='0001'
Fatura_Tarihi='22.05.2005'
Cari_Kod='MM AB 00001'
Cari_isim='Ahmet Sorsecer'
ve diğer fatura bilgileri s
Fatura_NO ='0002'
Fatura_Tarihi='22.12.2005'
Cari_Kod='AZ ZZ 20000'
Cari_isim=Murat Kuş'
ve diğer fatura bilgileri s
....
.
..
..
Böyle binlerce fatura var. Yani hangi fatura kime kesilmiş oldugunu cari_kod ve cari_isimden anlıyoruz.
ben burda demişimki.Carikart dosyaasını soyle değiştirsem
Cari_Kod='MM AB 00001'
Cari_isim='Ahmet Sorsecer'
Adres=' istiklal caddesi '
Cari_ID='1'
-
Cari_Kod='MM AB 00002'
Cari_isim='Mehmet Gecici'
Adres=' Vatan Caddesi '
Cari_ID='2' // smallint bir sayı ve devamlı artan bir sayı kayıt sırasıda trigerla otomatik versem
Fatura dosyasınıda
Fatura_NO ='0001'
Fatura_Tarihi='22.05.2005'
Cari_ID='1'
ve diğer fatura bilgileri s
Fatura_NO ='0002'
Fatura_Tarihi='22.12.2005'
Cari_ID='2'
ve diğer fatura bilgileri s
yani cari_kod ve cari_isimi kaldırsam fatura dosyasıdan.
Bu işlemde tek cekindigiğim raporlardaki hız sorunum.
select * from fatura
where cari_kod between ''MM AB 00001' between ''MM AB 90001' desem
birinci mantıkla (yani cari_id olmayan)sorunum yok hemen gelicek ama mantıklı bir modelleme olan ikinci yontemde ise bu aralıktaki cari_id leri belirleyim sonra select demem gerekecek buda cok uzun bir yontem olacak bunun pratigini tartışıyorum.
2. sordugum ise bu fatura da zaten cari ve stok bilgileri var yani bu faturanın ne kadar tutarı oldugunu bir daha gidip cari hareket diye bir baska dosyaya işlemek yine fatura da olan stokların giriş cıkıslarınıda gidip stok hareket dosyasına yazmak bunu yapmak da ki tek amac bir cair veya stok raporu aldıgında hız problemini cozmek.
database fundementals& design tarzı kitapları anlayarak okuyacamda nerden bulabilirim bilgi lutfen
tesekuur ederim.
[/b]
Demek istediğim su bir carikart dosyamız var bir tanede fatura dosyamız var.Tarih: Prş Oca 05, 2006 2:42 Mesaj konusu:
2-Tekrar eden bilgileri smalint (kod_id)bir degiskene atayıp sadece select lemi ceksem yada firebirdin yapısı guclu oldugu için ilgili yerlere tekrar bunları yazsam performans acısından degisen bir sey olurmu.
yani Söyle bir sey olsa Cari_Kod , Cari_isim, Adres,Kod_ID alalarını oldugu bir cari kart bir table olsa. Fatura dosyasında Cari_Kod, Cari_isim,Fatura_Tarihi, v.s bilgileri olsa. iyi bir modellemede iki alternatif var.
Cari_Kod='00001'
Cari_isim='Ahmet Sorsecer'
Adres=' istiklal caddesi '
Kod_ID='Gen_ID('Cari_Kod') olsun yani her bir yeni kayıtta bir smalint bir sayı üretilse
Fatura Dosyasında Sadece Kod_Id yi kullansam yani cari_kod,cari_isim ve adres alanlarını kaldırsam ve bütün raporlarda select ile Cari kart dosyasına bağlantı kurup where kod_id ile Cari_kod ve Cari_isim ve Adresi Ceksem Vt tarafıda doğru bir modelleme olucak amma evet amma direk fatura dosyasına kod_id yerine cari_kod ve cari_isim tekrar yazsam raporlamalarda kat kat hız kazanıyorum cunku örnek bir rapor cari_kod aralığı istenince kod_id li bir modllemede yavas lama oluyor diğerinde direk between kullanılabiliniyor.
Bu arada primary key cari_kod tabiki,
profesyonelce bir vt nasıl olmalı
>>
Ne demek istediğini tam anlamadım ama,
Carikart dosyamızda
Cari_Kod='MM AB 00001'
Cari_isim='Ahmet Sorsecer'
Adres=' istiklal caddesi '
Cari_Kod='MM AB 00002'
Cari_isim='Mehmet Gecici'
Adres=' Vatan Caddesi '
...
...
...
Cari_Kod='ZZ ZZ 90002'
Cari_isim='Oktay Veli'
Adres=' serenler mahallesi '
bilgileri var.
Fatura keserken
Fatura_NO ='0001'
Fatura_Tarihi='22.05.2005'
Cari_Kod='MM AB 00001'
Cari_isim='Ahmet Sorsecer'
ve diğer fatura bilgileri s
Fatura_NO ='0002'
Fatura_Tarihi='22.12.2005'
Cari_Kod='AZ ZZ 20000'
Cari_isim=Murat Kuş'
ve diğer fatura bilgileri s
....
.
..
..
Böyle binlerce fatura var. Yani hangi fatura kime kesilmiş oldugunu cari_kod ve cari_isimden anlıyoruz.
ben burda demişimki.Carikart dosyaasını soyle değiştirsem
Cari_Kod='MM AB 00001'
Cari_isim='Ahmet Sorsecer'
Adres=' istiklal caddesi '
Cari_ID='1'
-
Cari_Kod='MM AB 00002'
Cari_isim='Mehmet Gecici'
Adres=' Vatan Caddesi '
Cari_ID='2' // smallint bir sayı ve devamlı artan bir sayı kayıt sırasıda trigerla otomatik versem
Fatura dosyasınıda
Fatura_NO ='0001'
Fatura_Tarihi='22.05.2005'
Cari_ID='1'
ve diğer fatura bilgileri s
Fatura_NO ='0002'
Fatura_Tarihi='22.12.2005'
Cari_ID='2'
ve diğer fatura bilgileri s
yani cari_kod ve cari_isimi kaldırsam fatura dosyasıdan.
Bu işlemde tek cekindigiğim raporlardaki hız sorunum.
select * from fatura
where cari_kod between ''MM AB 00001' between ''MM AB 90001' desem
birinci mantıkla (yani cari_id olmayan)sorunum yok hemen gelicek ama mantıklı bir modelleme olan ikinci yontemde ise bu aralıktaki cari_id leri belirleyim sonra select demem gerekecek buda cok uzun bir yontem olacak bunun pratigini tartışıyorum.
2. sordugum ise bu fatura da zaten cari ve stok bilgileri var yani bu faturanın ne kadar tutarı oldugunu bir daha gidip cari hareket diye bir baska dosyaya işlemek yine fatura da olan stokların giriş cıkıslarınıda gidip stok hareket dosyasına yazmak bunu yapmak da ki tek amac bir cair veya stok raporu aldıgında hız problemini cozmek.
database fundementals& design tarzı kitapları anlayarak okuyacamda nerden bulabilirim bilgi lutfen
tesekuur ederim.
[/b]
-
Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
Hmm.... o zaman pasta ve gazoz kalsın.
1. sorun: evet yaptığın doğru, yani binary cari_id iyi bir yöntem. hız sorunun olmaz. string cari koduyla oynasan bile bunu kayıtlara yansıtman gerekmez. bu çok büyük esneklik. uzun bilginin tekrarı azalıyor ve
tipi daha güçlü.
string cari kodun eğer belli standart uzunluktaysa ya da yakın.. o zaman
varchar yerine char kullan derim. içinde türkçe karakter kullanmayacaksan char setini ASCII bile verebilirsin. 3 bytelık karakter yerine 1 byte tutar.
cari kayıtların 30 bini aşma riski olabilir, projeni tam bilmiyorum. silinip eklenenler oldukça generatorun büyüyecektir. Integer tutman gerekebilir.
2. sorun: doğru hatırlıyorsam, faturayla ilgiliydi..
Fatura master ve detail olacak büyük ihtimalle. masterinda fatura tutarını ve kalem sayısını tutabilirsin böylece her seferinde kalemleri hesaplaman gerekmez, işlem hızlı olur. ama burada, master ve detail kayıt update işlemlerini aynı transaction içinde tutarlı yapman gerekecek.
kalemlerden bile hesaplasan korkma, FB milyonlarca kayıt içinden bile aradığın kriterleri çtönk diye toplayıp sana verir.
FB aynı anda kriterlere uygun bütün indexleri kullanabilen nadir bir RDBMS dir. yani tek bir indexle arayıp bayılmaz.
Korkundan anladığım kadarıyla daha önce paradox tarzı bişeyler kullanmışsın sen...
kitap konusuna gelince bilemiyorum, ben hiç kitap okumam,
digital bir arıza var bende 2 paragraf okuyunca uyku moduna giriyorum.
ama dur sana bi link vereyim, amazonda, hepsiburadada da vs araştır..
http://www.firebird-books.net
Kolay gelsin, takıldığın yerlerde sor.
1. sorun: evet yaptığın doğru, yani binary cari_id iyi bir yöntem. hız sorunun olmaz. string cari koduyla oynasan bile bunu kayıtlara yansıtman gerekmez. bu çok büyük esneklik. uzun bilginin tekrarı azalıyor ve
tipi daha güçlü.
string cari kodun eğer belli standart uzunluktaysa ya da yakın.. o zaman
varchar yerine char kullan derim. içinde türkçe karakter kullanmayacaksan char setini ASCII bile verebilirsin. 3 bytelık karakter yerine 1 byte tutar.
cari kayıtların 30 bini aşma riski olabilir, projeni tam bilmiyorum. silinip eklenenler oldukça generatorun büyüyecektir. Integer tutman gerekebilir.
2. sorun: doğru hatırlıyorsam, faturayla ilgiliydi..
Fatura master ve detail olacak büyük ihtimalle. masterinda fatura tutarını ve kalem sayısını tutabilirsin böylece her seferinde kalemleri hesaplaman gerekmez, işlem hızlı olur. ama burada, master ve detail kayıt update işlemlerini aynı transaction içinde tutarlı yapman gerekecek.
kalemlerden bile hesaplasan korkma, FB milyonlarca kayıt içinden bile aradığın kriterleri çtönk diye toplayıp sana verir.
FB aynı anda kriterlere uygun bütün indexleri kullanabilen nadir bir RDBMS dir. yani tek bir indexle arayıp bayılmaz.
Korkundan anladığım kadarıyla daha önce paradox tarzı bişeyler kullanmışsın sen...
kitap konusuna gelince bilemiyorum, ben hiç kitap okumam,
digital bir arıza var bende 2 paragraf okuyunca uyku moduna giriyorum.
ama dur sana bi link vereyim, amazonda, hepsiburadada da vs araştır..
http://www.firebird-books.net
Kolay gelsin, takıldığın yerlerde sor.
Firebird Foundation Member #208
http://www.firebirdsql.org
http://www.firebirdsql.org
Tesekkur ederim farkındayım ki bir gazozla bunlar olmaz Yok abi ben bilginin öneminin farkıydayım eğer mümkünse elimden geleni yaparım.
Cari_id de modelleme olarak iyi bir yontem ama burda sıkıntım su su cari kod aralıgındaki lerin aldıgı faturalar diye bir rapor istendiginde bu sp oluşturulurken where sorgusuna ne yazacam. Joinler carikart dosyasını birleştirecem mecburen buda mantıklı değil gibi. bu problem.Cunku fatura dosyasında sadece cari_id var. bu tip sorgularda sorun olacak gibi
Birde char kullanayı dusunuyorumdum makisimum 20 karekterlik bir kod olacak. Ama artık turkce kullandırmam ve CHAR setini ASCII derim ve COLLATE sinide ASCII diyecem.
2. sordugum ise bu fatura da zaten cari ve stok bilgileri var yani bu faturanın ne kadar tutarı oldugunu bir daha gidip cari hareket diye bir baska dosyaya işlemek yine fatura da olan stokların giriş cıkıslarınıda gidip stok hareket dosyasına yazmak mı yazmamak mı. Yazmak daki tek amac bir cari veya stok raporu aldıgında hız problemini cozmek. Boyle raporlarda gidip sadece cari hareket dosyasında select cekmek ve ya stok ile ilgili raporlarda sadece stokhareket dosyasına select cekmek daha hızlı amma bence bu iki hareket dosyasınada gerek yok cunku faturadaki bilgiler buna yazılacak aynı bilgi bir daha neden yazılsınki guclu olan firebird.
tesekkur ederim
Şu ana kadar öğrendiklerim bile daha mantıklı bir modelleme yapmama sebep oluyor ama daha cok öğrenilecek sey var. Vermiş olduğunuz siteye baktım ama ah ingilizce ah. Cok iyi degil ingilizcem calismaya basladım ingilizceye onuda öğrenecem.
Yok abi ben bilginin öneminin farkıydayım eğer mümkünse elimden geleni yaparım. Cari_id de modelleme olarak iyi bir yontem ama burda sıkıntım su su cari kod aralıgındaki lerin aldıgı faturalar diye bir rapor istendiginde bu sp oluşturulurken where sorgusuna ne yazacam. Joinler carikart dosyasını birleştirecem mecburen buda mantıklı değil gibi. bu problem.Cunku fatura dosyasında sadece cari_id var. bu tip sorgularda sorun olacak gibi
Birde char kullanayı dusunuyorumdum makisimum 20 karekterlik bir kod olacak. Ama artık turkce kullandırmam ve CHAR setini ASCII derim ve COLLATE sinide ASCII diyecem.
2. sordugum ise bu fatura da zaten cari ve stok bilgileri var yani bu faturanın ne kadar tutarı oldugunu bir daha gidip cari hareket diye bir baska dosyaya işlemek yine fatura da olan stokların giriş cıkıslarınıda gidip stok hareket dosyasına yazmak mı yazmamak mı. Yazmak daki tek amac bir cari veya stok raporu aldıgında hız problemini cozmek. Boyle raporlarda gidip sadece cari hareket dosyasında select cekmek ve ya stok ile ilgili raporlarda sadece stokhareket dosyasına select cekmek daha hızlı amma bence bu iki hareket dosyasınada gerek yok cunku faturadaki bilgiler buna yazılacak aynı bilgi bir daha neden yazılsınki guclu olan firebird.
tesekkur ederim
Şu ana kadar öğrendiklerim bile daha mantıklı bir modelleme yapmama sebep oluyor ama daha cok öğrenilecek sey var. Vermiş olduğunuz siteye baktım ama ah ingilizce ah. Cok iyi degil ingilizcem calismaya basladım ingilizceye onuda öğrenecem.
Tabloda olabilecek kayıt sayısınca SmallInt yada Integer her ne ise bir ID master key alanının olması, VT tasarımında özellikle master/detail ilişkilerde olmazsa olmazlardandırmusti yazdı:.. Cari_id de modelleme olarak iyi bir yontem ama burda sıkıntım su su cari kod aralıgındaki lerin aldıgı faturalar diye bir rapor istendiginde bu sp oluşturulurken where sorgusuna ne yazacam. Joinler carikart dosyasını birleştirecem mecburen buda mantıklı değil gibi. bu problem.Cunku fatura dosyasında sadece cari_id var. bu tip sorgularda sorun olacak gibi
Endişelendiğin konuyu ise cari_kod ve cari_ad alanları için ikincil indeksler (foreing key) oluşturmak hız sorununu bertaraf etmenizi sağlayacaktır. Cari_Kod'lar arası bir sorgu için ana tablo cari, join lenecek tablo ise fatura ve fatura_detay tabloları olmalı 
Fatura_detayında zaten miktar ve birim fiyat yazdığında tutar bellidir. BirimFiyat * BirimFiyat sonucu çıkan tutarda herhangi bir iskonto varsa ayrıca her kalem için hesaplanan tutar yanında satış_tutarı diye bir alan eklemek yeterli olabilir.. Ayrıca tüm fatura üzerinden de indirim/iskonto olabileceği düşünülerek, faturanın genel_tutarı ve satış_tutarı fatura_master tablosunda da tutulabilirmusti yazdı:.. 2. sordugum ise bu fatura da zaten cari ve stok bilgileri var yani bu faturanın ne kadar tutarı oldugunu bir daha gidip cari hareket diye bir baska dosyaya işlemek yine fatura da olan stokların giriş cıkıslarınıda gidip stok hareket dosyasına yazmak mı yazmamak mı. Yazmak daki tek amac bir cari veya stok raporu aldıgında hız problemini cozmek. ..
Edindiğin bilgileri güzelce derleyip konu ile ilgili güzel bir makale haline getirebilirsin meselamusti yazdı: Tesekkur ederim farkındayım ki bir gazozla bunlar olmaz
Bilgiyi paylaşarak artıralım! Hayatı kolaylaştıralım!!
-
Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
Bişeyleri sorgulaman veya performans sorun olmaz, takılınca burada sor hem herkes de bişeyler öğrenmiş olur.
sen sadece cari kart dosyasına yazacaksın cari_kod bilgisini, o yüzden
2-3 KB yer kazanacam diye ASCII tanımlaman ve kullanıcıyı kısıtlaman gerekmez. benimkisi sadece sana bilgi vermek amacıydı.
querylerini kolayca join edebilirsin ya da SP yazabilirsin
dediğin gibi
select ck.kodu,ch.tutar
from cari_kart ck
join cari_hareket ch on ch.cari_id=ck.id
where ck.kodu between 'XXXXXX' and 'YYYYYY'
burada başka kısıt vermezsen YIL vb, o zaman her carikartın her hareketini getirecektir bu da kartezyen çarpım demektir. dikkatli kullanman gerekir.
Bütün tablolarına ID diye bir primary saha açmalısın, ilişkileri bununla kurmalısın.
Sen o projeni hayır amaçlı yapıyorsan, gazozu pastayı ben sana ısmarlarım merak etme..
sen sadece cari kart dosyasına yazacaksın cari_kod bilgisini, o yüzden
2-3 KB yer kazanacam diye ASCII tanımlaman ve kullanıcıyı kısıtlaman gerekmez. benimkisi sadece sana bilgi vermek amacıydı.
querylerini kolayca join edebilirsin ya da SP yazabilirsin
dediğin gibi
select ck.kodu,ch.tutar
from cari_kart ck
join cari_hareket ch on ch.cari_id=ck.id
where ck.kodu between 'XXXXXX' and 'YYYYYY'
burada başka kısıt vermezsen YIL vb, o zaman her carikartın her hareketini getirecektir bu da kartezyen çarpım demektir. dikkatli kullanman gerekir.
Bütün tablolarına ID diye bir primary saha açmalısın, ilişkileri bununla kurmalısın.
Sen o projeni hayır amaçlı yapıyorsan, gazozu pastayı ben sana ısmarlarım merak etme..
Firebird Foundation Member #208
http://www.firebirdsql.org
http://www.firebirdsql.org
Recep abi makale yazmak kim ben kim siz ustadlar varken bize dusen sadece makalein kalemliğini yapmak olur sanırım.
Ama kendimi ne zaman hazır hissederim o zaman yazarım abi.
Cunku makale yazmak sorumluluk gerektiren birsey ve cok ciddi bir bilgi olması lazim kulaktan dolma bilgilerle veya yanlis bir bilgi ile allah korusun kac kisinin canı yanar. Bu formda ki bilgilerin önemide sanırım bu ciddetten geliyor.
Terminator abi
yani ID yi Cari_Kod olarak kullanırsam uninon gibi ayrıca birlestirme ihtiyacı duymam. Ama tabiki dogru olanı yapmak isterim.
Fatura gibi formlarda hesaplamayı sp ye mi bırakmak mantıklı yoksa Queryinin ondatachange olayın fomda kod yazarak hesaplamak mı. Bu hesaplama basitce a* b değil tabiki bunların indirimleri var ek fiyatları var kdvler var artı otv ler var.
Mantık olarak view i sadece hazır olan raporlar icin kullanacam örneğin kodu, ad, OdenenYardım istendigi zaman view aynı raporu tarih aralıklı istersem bunu sp ile yapacam (Gerci view in altına where tarih dedimmi geliyor ama yavasliyor)
Ayrıca Raporlar icin datasede readonly acan ayrı bir exe dusunuyorum yada datasede readonly acıp Query lere baglasam daha hızlı bir rapor alırım sanırım.
Master detailli fatura doyasında bu pk yi de Direk Fatura_No sunu vermek yerine yine kendi kendine artan bi ID mi vermek mi hep burda takılıyorum.
Şumudur pk yi varchar yerine Id (integer ) ver diğerlerini join yap.
Not: Sp ler ilgili Turkce kaynak varmı bildiginiz.
Ama kendimi ne zaman hazır hissederim o zaman yazarım abi.
Cunku makale yazmak sorumluluk gerektiren birsey ve cok ciddi bir bilgi olması lazim kulaktan dolma bilgilerle veya yanlis bir bilgi ile allah korusun kac kisinin canı yanar. Bu formda ki bilgilerin önemide sanırım bu ciddetten geliyor.
Terminator abi
Bu ID yi Integer bir otomatik artan bir sayı ile vermek ile direk 20 karekterlik (masterda Unique olan ) varcchar bir cari_kod vermek arasında acıkcası kararsızım ID vermek mantıklı olsada cari_kod pk yapmak daha performanslı geliyor.Bütün tablolarına ID diye bir primary saha açmalısın, ilişkileri bununla kurmalısın.
yani ID yi Cari_Kod olarak kullanırsam uninon gibi ayrıca birlestirme ihtiyacı duymam. Ama tabiki dogru olanı yapmak isterim.
Fatura gibi formlarda hesaplamayı sp ye mi bırakmak mantıklı yoksa Queryinin ondatachange olayın fomda kod yazarak hesaplamak mı. Bu hesaplama basitce a* b değil tabiki bunların indirimleri var ek fiyatları var kdvler var artı otv ler var.
Mantık olarak view i sadece hazır olan raporlar icin kullanacam örneğin kodu, ad, OdenenYardım istendigi zaman view aynı raporu tarih aralıklı istersem bunu sp ile yapacam (Gerci view in altına where tarih dedimmi geliyor ama yavasliyor)
Ayrıca Raporlar icin datasede readonly acan ayrı bir exe dusunuyorum yada datasede readonly acıp Query lere baglasam daha hızlı bir rapor alırım sanırım.
Master detailli fatura doyasında bu pk yi de Direk Fatura_No sunu vermek yerine yine kendi kendine artan bi ID mi vermek mi hep burda takılıyorum.
Şumudur pk yi varchar yerine Id (integer ) ver diğerlerini join yap.
Not: Sp ler ilgili Turkce kaynak varmı bildiginiz.
s.a.
türkçe kaynak bu site
çalışmalarızda başarılar.
evet odur.musti yazdı:Şumudur pk yi varchar yerine Id (integer ) ver diğerlerini join yap.
Not: Sp ler ilgili Turkce kaynak varmı bildiginiz.
türkçe kaynak bu site
çalışmalarızda başarılar.
Duyduğun Şeylerin Söylediklerim Olduğuna Eminim Ama
Anladığın Şeylerin Anlatmak İstediklerim Olduğuna Emin Değilim
Anladığın Şeylerin Anlatmak İstediklerim Olduğuna Emin Değilim
Yani burda
create table carikart( c_kod varchar(20),c_isim varchar(20),adres varchar(100))
pk c_kod
index c_isim
create table carihareket (c_kod varchar(20) ,tarih date ,borc numreic ,alacak numeric,aciklama varchar(100))
pk c_kod
fk carikat.c_kod
index tarih
den se bunu integer bir c_id olustutrak yapmak daha performanslı raporlar verir diyorsunuz
yani boyle yapalım
create table carikart(c_id integer, c_kod varchar(20),c_isim varchar(20),adres varchar(100))
pk c_id,
c_kod index unqiu
c_isim index
create table carihareket (c_id integer, ,tarih date ,borc numreic ,alacak numeric,aciklama varchar(100))
pk c_id
fk carikat.c_id
index tarih
create table carikart( c_kod varchar(20),c_isim varchar(20),adres varchar(100))
pk c_kod
index c_isim
create table carihareket (c_kod varchar(20) ,tarih date ,borc numreic ,alacak numeric,aciklama varchar(100))
pk c_kod
fk carikat.c_kod
index tarih
den se bunu integer bir c_id olustutrak yapmak daha performanslı raporlar verir diyorsunuz
yani boyle yapalım
create table carikart(c_id integer, c_kod varchar(20),c_isim varchar(20),adres varchar(100))
pk c_id,
c_kod index unqiu
c_isim index
create table carihareket (c_id integer, ,tarih date ,borc numreic ,alacak numeric,aciklama varchar(100))
pk c_id
fk carikat.c_id
index tarih
İlişkili tabloları c_kod ile değil de c_id ile bağlamak/ilişkilendirmek perfomansı artıracaktır. Hatırlarsak carikart ta c_kod adındaki string alanın sistemi hantallaştırmasını önlemek için böyle bir yöntemi tercih etmiştiik. Fakat carihareket tablosunda sadece c_id yi primary key vermek yeterli olmayacaktır. Çünkü öyle olursa her bir c_id için sadece bir hareket girebileceksin carihareket tablon için yine başka bir tabloya ilişkilendirmek için (mesela hareket özetini tutabileceğin bir hareket sabit tablosu için olabilir) h_id diye bir pk alan verebileceğin gibi, c_id + h_id (h_id her kayıtta bir artacak) bir pk da oluşturabilirsin. Burada işin inceliği c_id yi raporlamalarda hızlı olması için öne aldım. İndeks yapısını düşünürsek, aynı kişiye/carikart a ait bilgilerin yakın sayfa/page lerde olması sorguyu acayıp hızlandıracaktır
carihareket tablon için yine başka bir tabloya ilişkilendirmek için (mesela hareket özetini tutabileceğin bir hareket sabit tablosu için olabilir) h_id diye bir pk alan verebileceğin gibi, c_id + h_id (h_id her kayıtta bir artacak) bir pk da oluşturabilirsin. Burada işin inceliği c_id yi raporlamalarda hızlı olması için öne aldım. İndeks yapısını düşünürsek, aynı kişiye/carikart a ait bilgilerin yakın sayfa/page lerde olması sorguyu acayıp hızlandıracaktır Bilgiyi paylaşarak artıralım! Hayatı kolaylaştıralım!!