From: Fuat Altun (faltun@iso.org.tr)
Date: Mon 01 Mar 2004 - 12:55:56 EST
Merhabalar,
Benim kafam karistida :)
Yani yol olarak bir mi, iki mi, uc mu?
Hangisini tavsiye ediyorsunuz?
Tsk.
-----Original Message-----
From: Serdar K=D6YL=DC [mailto:serdarkoylu@fisek.com.tr]=20
Sent: Monday, March 01, 2004 4:59 PM
To: linux-programlama@liste.linux.org.tr
Subject: [linux-programlama] Re: tablo tasar=FDm=FD(konu disi)
Selamlar..
> > Selamlar..
> Selam ustat,
>=20
> Aslinda ben anlatmak istedigimi tam olarak anlatamadim. Biraz farkli
yoldan
> anlatayim;
Hayir, anliyorum. Piyasadaki X duzine muhasebe paketi de size bu
yaklasimi sunar zaten. Ama bu her zaman en dogru yaklasimdir denemez.
Asil konu, aslinda data olarak ayrilmis olan bolgeye bir tur akil
yuklenmesi olayidir.=20
Dogal olarak muhasebecilerin bu kodlama yontemini yillardan beri
kullanirlar. ETA veya Mikro gibi uygulamalarda 111.01.1200.81 icin
yazilan meblagin 111.01.1200, 111.01 ve 111 kodlu hesaplara da
eklenecegini bilirler, recursive olarak o isi kendileri yaparlar. Bu
kaydi eklerken de olabilecegi gibi, raporlari alirken de yapilabilir.
Siz ornegin hesap plani dokumu gibi bir liste isteyince bunu =
otomatikman
verirler.
Oysaki, pazarlama ilmi artik muhasebeden cok daha fazlasini
gerektiriyor. Aslen cogu kurumda muhasebe pazarlamanin disinda kalir.
Onlar aslen vergileri vs. odeyebilmek icin kesilen faturalari kaydi
zapta almak icin vardirlar. Oysaki gercek hayatta muhasebe =
raporlarindan
daha fazlasina ihtiyac vardir. Gelir Tablosu size kasada 1 Milyon lira
var der ama 3 gun sonra iscilerin maasi yatacak demez.=20
Alisilan duzen acisindan bu tur kodlama pek cok verim getirir. Fakat
surec boyunca, isletmenin gereksinimleri degistikce kodlama duzeninin
buna yetisemedigi gorulur. Bu tarafimdan defalarca yasanmistir. Diger
yandan CRM/ERP gibi kavramlarda bunu zorlastirir.=20
Eger Mali Musavirlik yapan XYZ firmasi icin bir uygulama yaziyorsaniz =
bu
tur kodlama cok anlamlidir. Fakat sizin olceklenebilirligi korumak =
uzere
bu tur manevralardan kacinmaniz cok daha iyi olacaktir. Dizayni bastan
iyi tutunki, musterinin yeri ve statusu vs. degisince sizin elinizdeki
veri hala dogru bilgiyi gosterebiliyor olsun.=20
En basit ornegini verdim. Eger bir musterinin isyeri degisirse sizde bu
degisiklikten sonra bir iade faturasi alirsaniz, bu kodlama sistemiyle
sadece muhasebe kayitlarinda anlamli bilgiler elde edersiniz. Oysa ki
yapilmasi gereken cok daha farkli bir islemdir. Kisaca, mesela, =
istanbul
musterilerini ayri bir tablo olarak tutun. Yani bir tabloda iller
bazinda islemler bulunsun. Bir baska tabloda ise bir baska ozellige =
gore
islemler vs. O zaman ne olur ? Oncelikle tablo enflasyonu. sonrasinda
cok zor esnetebileceginiz bir yapi. O zaman yapmak gereken hareketler
dosyasini SQL View's veya Index'ler (Non-SQL) yoluyla cesitli yonlerden
farkli sanal tablolar olarak kullanabilmektir. Bunun icinde siz eger bu
tur field ici attraksiyonlara girerseniz, iyi bir kodlama pratigi
getiremezsiniz. SQL icin bilhassa (PostgresSQL gibi cambazlarin =
bedavaya
oldugunu kabul ederek) field ici islem yapmaktansa, HAVING/GROUP
BY/WHERE kombinasyonlarinda uygun bir fieldi koymak cok cok daha =
verimli
olur. Diger yandan da kod sistemini degistirseniz dahi kodunuzu
degistirmek zorunda kalmazsiniz. 6 ay sac bas yolmus adamlar tanirim, =
bu
hatayi yapip X milyon hasta kaydi olduktan sonra kodun yetmediginden
dolayi veritabanini ve kodu bastan cirmalamis.. Her dakika X tane yeni
kayit eklenen bir veritabaninda oyle kolayca hareket edemezsiniz. =
Dahasi
durun kod bakimi yapiyorum, 2 saat bekleyin de diyemezsiniz. Cunku o
zaman hastalari acil servis yerine morga kaydetmeniz gerekebilir..
Kisacasi basit dusunun. Onun degisecegini, genisleyecegini dusunun.
yoksa bugun otomasyon programi satan bazilarinin basina geldigi gibi,
programinizi calistiran sirkete bir tane maasli adaminizi oturmak
zorunda kalabilirsiniz.
Diger yandan, bugun bunlari soylerken, bu karsi ciktigim hatalari eli
mahkum yapmis biri olarak soyluyorum. Cunku muhasebeciler bunu =
isterler.
Kisacasi, Muhasebe (Car/Stok vs. degil, mizan, bilanco vs. yapan bir
sey) yaziyorsaniz bu kodlama standardini kullanmaniz farz bir yerde.
Fakat bunu genellestirip her tur kod alanina sokmaya calismak (STOK
kodu, cari kodu vs.) uzun donemde sizi zora sokabilir, bilhassa SQL =
gibi
modern metotlarla. Bu kodlama paratigi COBOL uygulamalarinda pratikti.
Bir tur struct olusturyorduk filan.. DATA DIVISION'a yaz PIC XXX vs.,
PROCEDURE DIVISION'da MOVE kod TO fesmekan. vs. noktalari unutma... Ama
bilhassa SQL icin bu pratik, bir hayli oyunbozan olabiliyor vesselam..
> kendine gore bir kodlama mantigi kurmasidir. Ve bu mantigi da =
programa
> programci eklememeli. Zaten sozkonusu muhasebeciler olunca, her =
muhasebeci
> kendine gore birtakim kodlama standardi gelistirip bunu =
uygulamaktadir.
> Programcilarin da cari_kodu icin varchar(50) gibi bir tanimlama =
yapmasi
> normal sartlarda yeterli olur.=20
Ama her kullaniciyi bu tur zorlamalar icinde tutmamak daha dogru olur.
Programiniza yeterli akli eklerseniz, o zaman bu daha anlamli olur.
> Fakat global degilde, isyerine, tek bir yere
> ozel bir yazilim gelistiriliyorsa isteyen istedigi gibi hareket =
edebilir.
> Ben sadece bu bahsettigim yontemle bir muhasebecinin istedigi =
raporlari
> rahatlikla alabilip onemli detaylari stok_kodu ve cari_kodu =
alanlarini bu
> sekilde kullanarak yapabilindigini soyluyorum. Zaten piyasadaki =
mevcut
> muhasebe programlari da yazilimlarini bahsettigim sekilde sizlere
sunarlar.
> Sizin mevcut olanlardan daha iyisini yapmak adina yapacaginiz seyler =
en
> fazla ozel_kod1, ozel_kod2, ozel_kod3 gibi cari_kartlar tablosuna ek
alanlar
> eklemek. Bu alanlarin da isimleri icrali, blokeli gibi degil, =
ozel_kod1,
> ozel_kod2 gibi kullanicinin kendisinin tanimlayip ta tutabilecegi =
alanlar
> olmalidir. Bu da sizin ayri field olayiniza geliyor. :-) fakat ek =
field ta
> ekleseniz benim ornedigimle birlikte ek fieldlari da birlestirince =
iste o
> zaman bu is kokunden cozulmus olabilir. Birde benim onerdigim sadece =
il
> bazinda ayirimlardan ibarettir. Siz bunu belli urunu alan musterilere =
gore
> yapabilirsiniz, buyuk firma - kucuk firmaya gore yapabilirsiniz. =
Kriterler
> farkli olabilir. Farkli olan kritere gore de siz 3 - 5 tane field =
koyun,
> gerisini kullanici bu ek fieldler ile, ve hesap_kodu alanlari ile =
birlikte
> tek basina halledebilir.
Asil husus su ki, pek cok uygulama elindeki bilgilerden dinamik
cikartimlar yapmaktan acizdir. Ornegin, veritabanina genelde yazilan
seyler sadece kullanicinin girdigi bilgiler olur. Oysaki veri tabani
icinde o bilgiyi yorumlayabilmenizi saglayan bilgileri de tutarsaniz,
bir tur otomatik akla sahip olursunuz ve isiniz kolaylasir. Basitce, su
abonelerinin ihbarnamelerini bastirdiginizi farzedin. Asil konu su, tek
sayili kapi numaralari bir tarafta, cift sayili olanlar karsi tarafta
sokakta. Simdi siz bunu kaydederken sokagin hangi tarafinda olduguna
dair bir field eklerseniz, sorgulama hizinda da sorgulama komutlarinda
da rahat edersiniz.=20
Kisacasi, programlar insanlarin hayatini kolaylastirmak icin vardir.
Onlara kod sistemi icat etmek zorlugu getirmemelidir..
Saygi ve sevgiler..