Cari+Muhsabe veri tabanı tasarımı

Delphi'de kod yazma ile ilgili sorularınızı bu foruma yazabilirsiniz.
ikutluay
Üye
Mesajlar: 2341
Kayıt: 03 Tem 2007 10:13

Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen ikutluay »

Merhaba;

Arkadaşlar epeydir forumdan uzağım. Zaten uzak olduğum süre içinde genel olarak tarihle ilgili vs çiziktirmek gibi farklı alanlarda uğraş veriyordum.

Sonuçta kendimi geliştirmek için ufak ufak teşekküllü bir yazılımın altına elimi koyaym dedim.

Konuya uzatmadan meramıma gireyim.

Stok, Çek,Senet, Sipariş, Kasa, Satış, İrsaliye, İade vs Cari hareketler ile Muhasene kısmını içeren kendi çapımda bir yazılımı yazmayı deneyeyim diyorum.

Ancak ;

bu işlerde hemen kodlamaya girişen bir çok insan için sonuç hüsran olmuştur.

Ben son bir kaç yıldır Mikro veritabanını oldukça iyi öğrendim.

sorgularken vs epey rahatım.

Uygulamayı yazarken mikro tabanını doğrudan kullansam sorun olur mu ne dersiniz ?

Ya da alan adlarını hafi mainipule etsem ?

Ya da bu tip bir uygulama için kullanmaya uygun bir veritabanını incelemek için önerirmisiniz?

Öte yandan mesela cari kart tablosuna illişkin tablo yapısını taslak olarak ben eklesem şurda şu olsun demeye aday ve gönüllü arkadaşlarımız var mı ?
Kişi odur ki, koyar dünyada bir eser. Eseri olmayanın yerinde yeller eser./Muhammed Hadimi
http://www.ibrahimkutluay.net
http://www.ibrahimkutluay.net/blog
omurolmez
Üye
Mesajlar: 187
Kayıt: 31 Eki 2012 11:41

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen omurolmez »

Ben sizin için keyifsiz yazacağım ama kötü bir niyetim yok. Yazdıklarımın sadece kişisel kanaatim olduğunu belirtmeme gerek yok.

Seçtiğiniz alanı tekrar gözden geçirmek isteyebilirsiniz.

* Seçtiğiniz alanda birden çok sayıda firmanın yıllardır geliştirdikleri hazır ürünleri var.
* Seçtiğiniz konu, bir kere geliştir yıllarca sat cinsi bir alan değil. Eğitimiydi mevzuat değişikliğiydi vb nedeniyle sürekli destek vermeniz gereken bir konu.
* Saha personeli gerektiren, tek başınıza rekabet etmekte zorlanacağınız bir konu.
* Teknik olarak hiçbir zorluğu olmasa da mevzuat nedeniyle bir sürü teferruatı olan bir konu.

Sonra bir sürü çaba harcayıp kişisel ilişkileriniz ile bir ya da iki kişiye verip öyle kalabilir.

Hastane-hasta takibi, muhasebe takibi, süpermarket otomasyonu, üretim planlama (E.R.P) vb konuları seçerken iyi düşünmek gerekir. Ya belli bir bitçeyle ekip kurarak beş-on yıl sonra kar hedeflemeli, ya iflas eden bir firmayı satın alıp hazır bir şeylerle başlamalı ya da hiç başlamamalıdır diye düşünüyorum.

Basit bir arama ile bile ücretli ücretsiz yüzlerce program bulabiliyorsunuz. Nasıl rekabet edebilirsiniz ki ? Fazladan ne katabilirsiniz ? Bu soruların cevaplarını iyi düşünmek ve öyle başlamak gerekli.

Sırf bu alanlarda (muhasebe, hasta-takip, hastane otom., sigorta, otel, üretim planlama) veya daha geniş bir perspektifte (sinema takip, market, su dağıtım, vb) ortalıkta yüzlerce yazılım var. Üzülüyorum onca emeğe. Kim bilir ne hayallerle ne mesailer harcayarak yazdılar sonra baktılar olmuyo internette bedava dağıtmaya başladılar.

Madem ki mikroda (ve mecburen muhasebe mevzuatında) uzmanlığınız var, Mikro veya başka bir yazılım firmasında yazılımcı ya da danışman olarak çalışmayı düşünebilirsiniz. Sizin için daha verimli / daha karlı olabilir mi acaba ?

Aslında, yıllardır müşterilerimizde veya başka yerlerde gözlemlediğim şeyleri, yeni arkadaşlara genel olarak yazmak istedim. Amatör kalan yazılımlar, sadece yazarına değil o yazılımları kullanan firma veya kişilere bile bir süre sonra ayak bağı oluyor .

Gelişen teknoloji ile birlikte internet-tablet-akıllı telefon birlikteliğine yönelmeli, gerek bireyler gerekse ülke olarak henüz yapılmamış konular üzerine fikir üretmeliyiz.
Ömür Ölmez
Kullanıcı avatarı
ender_arslanturk
Kıdemli Üye
Mesajlar: 709
Kayıt: 18 Şub 2005 03:38
Konum: İstanbul

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen ender_arslanturk »

Selâm,

Bu gibi çalışmalar her şeyden evvela uzun bir süreç gerektirir. @OmurOlmez arkadaşa katılmakla beraber artık Türkiye de ticari program konularında yüzlerce firma bulunmaktadır. Bunu düşünürseniz piyasadan pay alabilmek için bazı konularda farkınız olmalıdır. ve iyi kazanabilmek için bir dağıtım kanalınız olmalıdır. Vesselâm..

Mevcut bir mimari yapıyı manipüle etmektense kendi yapınızı kurmanız önemlidir. Zira ileri ki zamanlarda da zaten kendi yapınızın bile değişmesi söz konusu olabilir. Alacak-verecek konuları hassas bir konudur. O yüzden bu konuda tanımlar olarak kasa, stok, cari oluştururken bunların hareketlerini de ayrıca tablolar halinde yapmalısınız (kasahareketleri, stokhareketleri, carihareketleri, vs. vs.) her tanımlara bir numara atayarak hareketlerle bu numara üzerinden bağ kurulabilir.

Ama "ufak ufak teşekküllü" dediniz ya.. İsterseniz piyasa 1 TL ye 2 TL ye veya 5 - 10 TL ye satabileceğiniz yazılımlara yönelin derim.. Misal www.gonulkitabi.com

Yani benzer projeler yapılarak hem insanların ihtiyacına bir cevap vermiş olursunuz, hem Ümmetin envanterine bir eser kazandırmış olursunuz hem de rakamların küçük olmasından dolayı sorumluluğu olmayan bir projeden bir dağıtım kanalı bulunarak çok kazanç elde edebilirsiniz. :)

Vesselâm..
ikutluay
Üye
Mesajlar: 2341
Kayıt: 03 Tem 2007 10:13

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen ikutluay »

Arkadaşlar ;

Yazılımcılık benim doğrudan ekmeğimi kazandığım iş değil. Asıl network desteğinden ekmeğim çıkıyor. Ama ben körelmemek için bir de seviye atlamak için bunu yapmak istedim. Dolayısıyla Eta,Mikro, netsis olmak gibi bir derdim yok.

Ayrıca mikro database yapısını sorguluyor olmam nedeniyle master detail yapısını zaten az çok herkes gibi bende biliyorum.

Benim derdim bu konuda kafa yorup kendimi daha da aşmak.

Mesela bir arkadaşım idendity kullanmıyor. Mikro ise hem identity kullanıyor hemde o değerler aynı rakamı başka bir fieldda daha tutuyor.

Ben bu tip bir tasarımı sağlamca kafamda oluşturup sonra işe girişmek istiyorum.

Zaman sıkıntım yok (boş oldukça yazacağım).

Kar etme derdim yok.

Mikrodan etadan iyisini yazma derdim yok.

Ama bunları yazanda sizin benim gibi insan evladı.
Kişi odur ki, koyar dünyada bir eser. Eseri olmayanın yerinde yeller eser./Muhammed Hadimi
http://www.ibrahimkutluay.net
http://www.ibrahimkutluay.net/blog
Kullanıcı avatarı
esistem
Üye
Mesajlar: 464
Kayıt: 02 Eki 2007 11:22
İletişim:

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen esistem »

Selam;
Ne ender_aslanturk nede omurolmez arkadaşa maalesef katılmıyorum. Mikro, logo, eta vs.vs. hemen hemen bütün hepsinin firmalarda ne şekilde kullanıldığını çok uzun zamandır görüyorum, takip ediyorum. Benim karşılaştığım firmaların %5 i belki tam anlamı ile kullanabiliyordu satın aldığı programları. Bu güne kadarda birçok firmaya kullanmış olduğu muhasebe programları haricinde basit kullanımlı, esnafın anlayabileceği dilde ön muhasebe program verdim. Bana kalırsa Türkiyede hala küçük esnaf olarak görülen ama kullanacak program bulamayan (bulsada kullanmayı beceremeyen) binlerce firma var. Birçok firma sahibinden, veya firmada çalışan muhasebe elemanından "kardeşim bana içinde anlamını bilmediğim tabirler olmayan, basit kullanımlı, herşeyi bir arada görebileceğim bi program ver" gibi söylemler ile karşılaştım. Veya "ya kardeşim böle bi program aldık ama şu raporu bir türlü alamıyoruz, aldığımız firmada paket program bu deyip ekleme yapmıyor" şeklinde çok yakınma duydum.

omurolmez arkadaşın dediği gibi "internet-tablet-akıllı telefon birlikteliğine yönelmeli". Programınızda bu özelliklerde bulunması size + değer katacaktır. Fakat iş program yazmakla kalmıyor maalesef, yazdığınız program elinizde öyle boş boş bekleyebilirde. Şu anki devir tamamen pazarlama devridir. Çok basit veya çok çok karmaşık bir programda yazabilirsiniz fakat onu satamadıktan sonra hiçbir işinize yaramaz. Yok ben satmasamda olur, başarmak bana yeter derseniz de sizin bileceğiniz iş.

Ben yakında öyle bir programı pazarlamaya başlıcam kısmetse, Ön muhasebe+lokanta ve cafelerin kullanımına uygun+Basit birde imalat modülü (Ürün reçetesi) gömülü bir program olacak, cep tlf, tablet pc, el terminalinden ulaşım vs.vs. olacak. Ben satmasamda olur diyorum, hatta böyle bir programı uzun zamandır ücretsiz dağıtmayıda düşünüyordum fakat artık onu yapamıcam sanırım, zira bulunduğum ilçede 3 firmaya satmak zorunda kaldım, haklarını yememek lazım. Nasıl sattın derseniz, muadili programlar 5.000-6.000 tl gibi rakamlara satılınca, "benim sokak arası büyük esnaf" dediğim firmalara bu programlar pahalı geliyor sizde eğer uygun fiyat verirseniz göreceksiniz ki satmamanız için hiçbir sebep yok. Bende öyle yaptım zaten. Birde müşterinize her aradığında desteğini verirseniz hiçbir sorun kalmaz.

Ama ender_aslanturk arkadaşın dediği gibi kendi veritabanı yapınızı kurmanız çok çok önemlidir. Daha ne diyelim yolunuz açık olsun.
ikutluay
Üye
Mesajlar: 2341
Kayıt: 03 Tem 2007 10:13

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen ikutluay »

Arkadaşlar konuyu zaten veritabanının nasıl gerektiğini tartışmak için açtım.

Mesela Identity kullanmayı tercih etmeyen arkadşaım şöyle yapıyor

sayac isimli tabloda table name ve sonref diye iki alan var. Her tablo için kullandığı son id'i buraya kaydedip, son id'yi de buradan çekiyor.

bakıldığında identity yerine daha iyi bir çözüm gibi görünüyor.

Buradan başlamış olalım...

Şimdi çıkmam gerek . Yarın kısmetse Cari kart tablosundan başlarım burada paylaşmaya
Kişi odur ki, koyar dünyada bir eser. Eseri olmayanın yerinde yeller eser./Muhammed Hadimi
http://www.ibrahimkutluay.net
http://www.ibrahimkutluay.net/blog
omurolmez
Üye
Mesajlar: 187
Kayıt: 31 Eki 2012 11:41

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen omurolmez »

@esistem
Teşekkürler, yazdığınız için. Madalyonun öbür yüzünden bir katılım faydalı oldu benim için ...
Ömür Ölmez
ikutluay
Üye
Mesajlar: 2341
Kayıt: 03 Tem 2007 10:13

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen ikutluay »

bu mikronun Cari kartlar için tuttuğu tablo.

Bu tabloya kayıt ekleyince bir sonraki adımda update ile "cari_recno" ya eklenen bilgiyi "cari_RECid_RECno" alanına update ile yazıyor.

Yapıda ihtiyaç duyulan tüm alanlar var gibi. Bakalım diğer arkadaşların yorumu ne olacak.

CREATE TABLE [dbo].[CARI_HESAPLAR] (
[cari_RECno] int IDENTITY(1, 1) NOT NULL,
[cari_RECid_DBCno] smallint NOT NULL,
[cari_RECid_RECno] int NOT NULL,
[cari_SpecRECno] int NULL,
[cari_iptal] bit NULL,
[cari_fileid] smallint NULL,
[cari_hidden] bit NULL,
[cari_kilitli] bit NULL,
[cari_degisti] bit NULL,
[cari_checksum] int NULL,
[cari_create_user] smallint NULL,
[cari_create_date] datetime NULL,
[cari_lastup_user] smallint NULL,
[cari_lastup_date] datetime NULL,
[cari_special1] nvarchar(4) COLLATE Turkish_CI_AS NULL,
[cari_special2] nvarchar(4) COLLATE Turkish_CI_AS NULL,
[cari_special3] nvarchar(4) COLLATE Turkish_CI_AS NULL,
[cari_kod] nvarchar(25) COLLATE Turkish_CI_AS NULL,
[cari_unvan1] nvarchar(50) COLLATE Turkish_CI_AS NULL,
[cari_unvan2] nvarchar(50) COLLATE Turkish_CI_AS NULL,
[cari_hareket_tipi] tinyint NULL,
[cari_tipi] tinyint NULL,
[cari_muh_kod] nvarchar(40) COLLATE Turkish_CI_AS NULL,
[cari_muh_kod1] nvarchar(40) COLLATE Turkish_CI_AS NULL,
[cari_muh_kod2] nvarchar(40) COLLATE Turkish_CI_AS NULL,
[cari_doviz_cinsi] tinyint NULL,
[cari_doviz_cinsi1] tinyint NULL,
[cari_doviz_cinsi2] tinyint NULL,
[cari_vade_fark_yuz] float NULL,
[cari_vade_fark_yuz1] float NULL,
[cari_vade_fark_yuz2] float NULL,
[cari_KurHesapSekli] tinyint NULL,
[cari_vdaire_adi] nvarchar(20) COLLATE Turkish_CI_AS NULL,
[cari_vdaire_no] nvarchar(15) COLLATE Turkish_CI_AS NULL,
[cari_sicil_no] nvarchar(15) COLLATE Turkish_CI_AS NULL,
[cari_VergiKimlikNo] nvarchar(10) COLLATE Turkish_CI_AS NULL,
[cari_satis_fk] int NULL,
[cari_odeme_cinsi] tinyint NULL,
[cari_odeme_gunu] tinyint NULL,
[cari_odemeplan_no] int NULL,
[cari_opsiyon_gun] int NULL,
[cari_cariodemetercihi] tinyint NULL,
[cari_fatura_adres_no] int NULL,
[cari_sevk_adres_no] int NULL,
[cari_banka_tcmb_kod1] nvarchar(4) COLLATE Turkish_CI_AS NULL,
[cari_banka_tcmb_subekod1] nvarchar(8) COLLATE Turkish_CI_AS NULL,
[cari_banka_tcmb_ilkod1] nvarchar(3) COLLATE Turkish_CI_AS NULL,
[cari_banka_hesapno1] nvarchar(30) COLLATE Turkish_CI_AS NULL,
[cari_banka_tcmb_kod2] nvarchar(4) COLLATE Turkish_CI_AS NULL,
[cari_banka_tcmb_subekod2] nvarchar(8) COLLATE Turkish_CI_AS NULL,
[cari_banka_tcmb_ilkod2] nvarchar(3) COLLATE Turkish_CI_AS NULL,
[cari_banka_hesapno2] nvarchar(30) COLLATE Turkish_CI_AS NULL,
[cari_banka_tcmb_kod3] nvarchar(4) COLLATE Turkish_CI_AS NULL,
[cari_banka_tcmb_subekod3] nvarchar(8) COLLATE Turkish_CI_AS NULL,
[cari_banka_tcmb_ilkod3] nvarchar(3) COLLATE Turkish_CI_AS NULL,
[cari_banka_hesapno3] nvarchar(30) COLLATE Turkish_CI_AS NULL,
[cari_EftHesapNum] tinyint NULL,
[cari_Ana_cari_kodu] nvarchar(25) COLLATE Turkish_CI_AS NULL,
[cari_satis_isk_kod] nvarchar(4) COLLATE Turkish_CI_AS NULL,
[cari_sektor_kodu] nvarchar(25) COLLATE Turkish_CI_AS NULL,
[cari_bolge_kodu] nvarchar(25) COLLATE Turkish_CI_AS NULL,
[cari_grup_kodu] nvarchar(25) COLLATE Turkish_CI_AS NULL,
[cari_temsilci_kodu] nvarchar(25) COLLATE Turkish_CI_AS NULL,
[cari_muhartikeli] nvarchar(10) COLLATE Turkish_CI_AS NULL,
[cari_firma_acik_kapal] bit NULL,
[cari_BUV_tabi_fl] bit NULL,
[cari_cari_kilitli_flg] bit NULL,
[cari_etiket_bas_fl] bit NULL,
[cari_Detay_incele_flg] bit NULL,
[cari_efatura_fl] bit NULL,
[cari_POS_ongpesyuzde] float NULL,
[cari_POS_ongtaksayi] float NULL,
[cari_POS_ongIskOran] float NULL,
[cari_kaydagiristarihi] datetime NULL,
[cari_KabEdFCekTutar] float NULL,
[cari_hal_caritip] tinyint NULL,
[cari_HalKomYuzdesi] float NULL,
[cari_TeslimSuresi] smallint NULL,
[cari_wwwadresi] nvarchar(30) COLLATE Turkish_CI_AS NULL,
[cari_EMail] nvarchar(80) COLLATE Turkish_CI_AS NULL,
[cari_CepTel] nvarchar(20) COLLATE Turkish_CI_AS NULL,
[cari_VarsayilanGirisDepo] int NULL,
[cari_VarsayilanCikisDepo] int NULL,
[cari_Portal_Enabled] bit NULL,
[cari_Portal_PW] nvarchar(127) COLLATE Turkish_CI_AS NULL,
[cari_BagliOrtaklisa_Firma] int NULL,
[cari_kampanyakodu] nvarchar(4) COLLATE Turkish_CI_AS NULL,
[cari_b_bakiye_degerlendirilmesin_fl] bit NULL,
[cari_a_bakiye_degerlendirilmesin_fl] bit NULL,
[cari_b_irsbakiye_degerlendirilmesin_fl] bit NULL,
[cari_a_irsbakiye_degerlendirilmesin_fl] bit NULL,
[cari_b_sipbakiye_degerlendirilmesin_fl] bit NULL,
[cari_a_sipbakiye_degerlendirilmesin_fl] bit NULL,
[cari_AvmBilgileri1KiraNo] int NULL,
[cari_AvmBilgileri1TebligatSekli] tinyint NULL,
[cari_AvmBilgileri2KiraNo] int NULL,
[cari_AvmBilgileri2TebligatSekli] tinyint NULL,
[cari_AvmBilgileri3KiraNo] int NULL,
[cari_AvmBilgileri3TebligatSekli] tinyint NULL,
[cari_AvmBilgileri4KiraNo] int NULL,
[cari_AvmBilgileri4TebligatSekli] tinyint NULL,
[cari_AvmBilgileri5KiraNo] int NULL,
[cari_AvmBilgileri5TebligatSekli] tinyint NULL,
[cari_KrediRiskTakibiVar_flg] bit NULL,
[cari_ufrs_fark_muh_kod] nvarchar(40) COLLATE Turkish_CI_AS NULL,
[cari_ufrs_fark_muh_kod1] nvarchar(40) COLLATE Turkish_CI_AS NULL,
[cari_ufrs_fark_muh_kod2] nvarchar(40) COLLATE Turkish_CI_AS NULL,
[cari_odeme_sekli] tinyint NULL,
CONSTRAINT [NDX_CARI_HESAPLAR_00] PRIMARY KEY CLUSTERED ([cari_RECno])
)
ON [PRIMARY]
GO

CREATE UNIQUE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_01] ON [dbo].[CARI_HESAPLAR]
([cari_RECid_DBCno], [cari_RECid_RECno])
WITH (
PAD_INDEX = OFF,
IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE UNIQUE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_02] ON [dbo].[CARI_HESAPLAR]
([cari_kod])
WITH (
PAD_INDEX = OFF,
IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_03] ON [dbo].[CARI_HESAPLAR]
([cari_unvan1])
WITH (
PAD_INDEX = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE UNIQUE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_04] ON [dbo].[CARI_HESAPLAR]
([cari_sektor_kodu], [cari_kod])
WITH (
PAD_INDEX = OFF,
IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE UNIQUE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_05] ON [dbo].[CARI_HESAPLAR]
([cari_grup_kodu], [cari_kod])
WITH (
PAD_INDEX = OFF,
IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE UNIQUE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_06] ON [dbo].[CARI_HESAPLAR]
([cari_temsilci_kodu], [cari_kod])
WITH (
PAD_INDEX = OFF,
IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE UNIQUE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_07] ON [dbo].[CARI_HESAPLAR]
([cari_bolge_kodu], [cari_kod])
WITH (
PAD_INDEX = OFF,
IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE UNIQUE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_08] ON [dbo].[CARI_HESAPLAR]
([cari_kaydagiristarihi], [cari_kod])
WITH (
PAD_INDEX = OFF,
IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_09] ON [dbo].[CARI_HESAPLAR]
([cari_Ana_cari_kodu])
WITH (
PAD_INDEX = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [NDX_CARI_HESAPLAR_10] ON [dbo].[CARI_HESAPLAR]
([cari_vdaire_no])
WITH (
PAD_INDEX = OFF,
DROP_EXISTING = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO
Kişi odur ki, koyar dünyada bir eser. Eseri olmayanın yerinde yeller eser./Muhammed Hadimi
http://www.ibrahimkutluay.net
http://www.ibrahimkutluay.net/blog
Kullanıcı avatarı
cengaver
Üye
Mesajlar: 111
Kayıt: 01 Nis 2014 05:02
Konum: İstanbul

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen cengaver »

Merhaba,

Identity kullanmama konusunda maalesef sana katılamıyorum zira Identity her bir kayda kimlik numarası vermek gibi bir şeydir. İndeksler oluştururken veya joinler kurarken hem performansa hem de SQL kodunun okunabilirliğine çık katkısı vardır. Yani Identity kullanmamak hakikaten bir macera olur diye düşünüyorum.

Bunun dışında şöyle bir şey demişsin;
ikutluay yazdı:Bu tabloya kayıt ekleyince bir sonraki adımda update ile "cari_recno" ya eklenen bilgiyi "cari_RECid_RECno" alanına update ile yazıyor.
Log tutuyor olabilir mi?...
ikutluay
Üye
Mesajlar: 2341
Kayıt: 03 Tem 2007 10:13

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen ikutluay »

Merhaba;

Ben incelediğim koda göre konuştum konuya dair bir önyargım yok. Zaten olması gerekeni araştırıyoruz. Ancak ilgili arkadaş ile de az önce konuşurken bu konu açıldı ve o da artık identy kullanılması gerektiğinden bahsetti.

Ancak her halükarda en uygun bu ID alanının yukarda mikronun yaptığı gibi 2. bir alanda da tutulması diye düşünüyorum

bunu log olarak değilde tabloya dışardan müdahale ile id alanları bozulursa detay verileri kaybetmemek için yapıyor olsa gerek. Böylece program dışında tablolara müdahale edilse de verilerin ilk hali kurtarılabilir.
En son ikutluay tarafından 10 Nis 2014 12:52 tarihinde düzenlendi, toplamda 1 kere düzenlendi.
Kişi odur ki, koyar dünyada bir eser. Eseri olmayanın yerinde yeller eser./Muhammed Hadimi
http://www.ibrahimkutluay.net
http://www.ibrahimkutluay.net/blog
Kullanıcı avatarı
cengaver
Üye
Mesajlar: 111
Kayıt: 01 Nis 2014 05:02
Konum: İstanbul

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen cengaver »

2. bir alanda da aynı verinin tutulması neye hizmet edecek ki? Bence israf olur.

Bunun dışında tablodaki bazı fieldler gözümü tekmeledi, mesela

Kod: Tümünü seç

[cari_AvmBilgileri1KiraNo] int NULL,
[cari_AvmBilgileri1TebligatSekli] tinyint NULL,
[cari_AvmBilgileri2KiraNo] int NULL,
[cari_AvmBilgileri2TebligatSekli] tinyint NULL,
[cari_AvmBilgileri3KiraNo] int NULL,
[cari_AvmBilgileri3TebligatSekli] tinyint NULL,
[cari_AvmBilgileri4KiraNo] int NULL,
[cari_AvmBilgileri4TebligatSekli] tinyint NULL,
[cari_AvmBilgileri5KiraNo] int NULL,
[cari_AvmBilgileri5TebligatSekli] tinyint NULL,
gibi fieldler bence bu tabloda değil farklı bir tabloda olmalı, zira bir cari hesabın bu tür birden fazla "olabilecek" sonsuz sayıda avm bilgileri olabilir. Bu örnekte ise sadece 5 ile sınırlı. O şekilde olursa hem daha efektif hem de daha verimli olur bence
ikutluay
Üye
Mesajlar: 2341
Kayıt: 03 Tem 2007 10:13

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen ikutluay »

orda haklısınız hele cari harekette var olan tevkifat alanları....

yaklaşık 40 tane...
Kişi odur ki, koyar dünyada bir eser. Eseri olmayanın yerinde yeller eser./Muhammed Hadimi
http://www.ibrahimkutluay.net
http://www.ibrahimkutluay.net/blog
omurolmez
Üye
Mesajlar: 187
Kayıt: 31 Eki 2012 11:41

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen omurolmez »

Mikro vb programları veritabanlarını incelemek tabii ki çok faydalı ama bir noktayı atlamamak gerekir.

Bu firmalar, yolun başında üç dört kişilik bir ekip iken hatalı tasarımlarla başlamış ve uzun süre böyle devam etmek zorunda kalmış olabilirler.
Örneğin eskiden Mikro da yıl sonu devir işlemi vardı. Ama böyle çalıştıkları zamanlar zayıf bir veritabanı kullanıyorlardı (Rdbms değildi).
Daha sonra Microsoft Sql Server kullanmaya başladılar. Yeni sunucunun gücü ile birlikte (ve belkide bilmediğim başka bazı nedenlerle) yıl sonu devir işlemini kaldırdılar.
Öyle ise şöyle sormalı ? Mikro nun hangi sürüm veritabanını inceliyorsunuz ? Mikro nun rakiplerine göre eksikleri / tasarım hataları olabilir mi ?
İncelediğiniz sürümde, Mikro nun bildiği ve kısa süre içinde değiştireceği bazı tasarım hataları / eksikler olabilir mi ?

Benzer şekilde yeni sunucunun gücü ile başka bir çok tasarım değişikliği yapılmış olabilir.
Örneğin, "veriler bozulursa" demişsiniz. Veriler bozulmaz, bozulmamalı. Bozuluyorsa, o veri tabanı sistemi kullanılmamalı (yıl 2014). Veritabanı sistemi, disk üstündeki dosyayı daima stable tutmalı. Yani elektriğin kesildi herhangibir anda, daima veri bütünlük içinde olmalı (consistency). En fazla commit edilmemiş transaction kaybedilmeli (Artık pdox/clipper mantığı, disk üstünde dosya kilitleme mantığı, ağ paylaşımı mantığı tarih oldu).

Diğer bir hata da "aynı alanın iki kere kullanılması israf olur". Bu yanlış, tasarımı / hata ayıklamayı kolaylaştıracaksa tonla byte harcanır. Hiç önemli değil. Yerel olarak verimliliğe odaklanmak yanlıştır. Küresel olarak tüm işin verimliliği ve sürdürülebilirliği önemlidir (Bkz: "Hatasız Kodlama" Steve Maguire).
Asıl sorun şudur. Aynı verinin birden fazla kopyasının tutulması, ciddi bir hatadır. Aynı işi yapan birden çok kod yazmak zorunda bırakır. Veri bütünlüğünü bozar ve algoritmada oluşacak hataların yakalanmasını güçleştirir.

Örneğin, aşağıdaki biçimlerden hangisi doğru tasarım olur diye düşünelim :
Belli tarihte belli miktar paranın iki hesap arasında transferinin kaydını nasıl tutabiliriz ?
A. Aşağıdaki tabloya iki tane kayıt ekleriz. Kayıtlar aynı tarihli olur fakat hesa_id farklı olur. Yine birinde borc alanına diğerinde alacak alanına değer yazarız.

tarih datetime,
cari_id int,
hesap_id int,
borc money,
alacak money

B. Aşağıdaki tabloya tek bir kayıt ekleriz. Miktarı yanlızca bir yerde yazarız. Elbette bu tablo yapısından rapor oluşturmak, ilk örnektekinden daha zahmetli olur.
Ancak miktar değerinin yanlızca bir defa yazıldığına dikkat edelim.
tarih datetime,
cari_id int,
hesap_id_veren int,
hesap_id_alan int,
miktar money

İkinci örnek nihai tasarım olmayabilir ve hata içerebilir. Amacım, doğru tasarımı ver(ebil)mek değil; günümüz bakış açısına dikkat çekebilmek (Windows 95 den bugüne gelişimi, yazılımcıların artık daha dikkatli olmalarından değil sürekli bakış açılarını iyileştirmelerinden dolayıdır).
Ömür Ölmez
Kullanıcı avatarı
esistem
Üye
Mesajlar: 464
Kayıt: 02 Eki 2007 11:22
İletişim:

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen esistem »

Selam;
omurolmez'in dediklerine tamamen katılıyorum ve çok çok ciddiye almanızı öneririm, özellikle aynı kayıtların tekrarlanması olayı geçmişten beri süregelen bir tartışmadır. Bunun en basit örneği kendi veritabanı tasarımlarımdır. Bana bir çok programcının söylediği "sen yanlış tasarım yapıyorsun" oluyor nedense.
Mesela fatura kayıtlarını 2 tabloda tutarım sürekli, fatura tablomda tarih, cari hesap kodu, saat, faturano, alissatis, toptanperakende, acikkapali vs.vs. gibi alanların hemen hepsi fatura_alt (stokların kayıtlı olduğu tablo) tablomdada vardır. İşte buna kayıt tekrarı diyorlar. zaten kayıtlı olan verileri tekrar alt tabloya yazmak byte israfı veya gereksiz deniyor. Fakat en basiti şu cari hesap en çok hangi malları hangi tarihlerde satın almış gibi bir raporu ana fatura tablosunu hiç sorguya sokmadan direk çekebiliyorum. Yada şu stok hangi tarihlerde kimlere satılmış gibi bir raporu ana fatura tablosunu sorguya hiç sokmadan alabiliyorsunuz.
birde sizin CARI kart tasarımınızda şu yapı bana çok ters geldi.

Kod: Tümünü seç

[cari_create_user] smallint NULL,
[cari_create_date] datetime NULL,
[cari_lastup_user] smallint NULL,
[cari_lastup_date] datetime NULL,
sanırım yukarıdakiler oluşturan user kim, hangi tarihte oluşturmuş, son değiştiren user kim hangi tarihte değiştirmiş anlamına geliyor.
Bunun yerine CARI kartına bağlı bir CARI_LOG tablosu oluşturup, alanlarını,

Kod: Tümünü seç

id, cariid, userid, date, time, durum=(0:insert,1:update gibi)
şeklinde verseniz ve bu cari karta yapılan her işlemi bu tabloya ekleseniz, bu cari karta hangi kullanıcı hangi tarihlerde ne şekilde müdehale etmiş çok güzel bir şekilde takip edebilirsiniz.
hatta daha da ileri gidip tek bir log tablosu oluşturun.

Kod: Tümünü seç

id, tabloadi, tabloid, ip, userid, date, time, durum=(0:insert,1:update,2:delete), aciklama [ip : vt ye bağlı bilg. IP nosu]
şeklinde bir yapı ile tüm vt nin logunu tutabilirsiniz ki ben öyle yapıyorum. Hangi tabloya kim hangi bilgisayardan hangi tarihte ne şekilde müdehale etmiş neleri oluşturmuş, değiştirmiş yada silmiş buradan takip ettiriyorum. Ve çok kullanıcılı bir sistemde patronun çok çok hoşuna gidiyor bu durum.
Kullanıcı avatarı
ender_arslanturk
Kıdemli Üye
Mesajlar: 709
Kayıt: 18 Şub 2005 03:38
Konum: İstanbul

Re: Cari+Muhsabe veri tabanı tasarımı

Mesaj gönderen ender_arslanturk »

Selâmlar,

@sistem arkadaşımın yazdıklarına elbette katılmamak mümkün değil. Fakat bu gibi uzun süreçli bir çalışma gerektiren sistemler de zaman, maliyet, satış devir hızı haricinde işin yalnızca satış noktasında değerlendirmemek gerekiyor. Yani burada müşterinin satın aldığı ürünün uzun vadeli kullanması ve kullanırken de verimliliğin yüksek olması önemlidir.

Ayrıca o kadar göreceli bir sektörden bahsediyoruz ki, geçenlerde gittiğim bir firmaya ürünlerimiz için 3000 TL ye yakın network ortamında çalışmak üzere bir fiyat modeli çıkarttığımda müşteri ben 800 tl ye sistemime ticari program alıyorum diyebiliyor. O yüzden tercihler noktası taaa en baştan doğru modellenmelidir. Bir de şöyle bir şey var. Ben bir daha para ödemem diye satışını gerçekleştirdiğiniz bir müşteri ye 250 TL lik satılan bir ürünün desteği ömür boyu verilemez.. :)

Ayrıca;

Hiç bir ticari sistem bir firmanın profiline % 100 oturmaz ! Hatta bazı firmaları kopyalayın 100 metre ileriye yapıştırın bu farklı noktadan dolayı sisteminin çok farklı olduğu da görülebilmektedir. Bunlar yaşadığımız tecrübeler. Ticari programlarda ki en büyük eksik ar-ge desteğidir. ! O sebeple satılan ürün şirketin profiline misal %70 oturduysa ve % 30 luk bir açık kaldıysa bu da ar-ge çalışmalarıyla projelendirilir. Nitekim www.visera.co ürünü için bu şekilde yapılmaktadır.

Dediğim gibi, görecesi çok olan ve uzmanlık gerektiren ve geliştirme süreçleri çok maliyetli olan bir uzmanlık bizimkisi. O yüzden "modelleme" olmazsa olmaz olmalıdır.

Konuya gelirsek.. Yukarıda ki veritabanı tablo modeline baktığımızda kendi özgü bir sistem olduğu ortada... Misal cari isim tablosunda carinin banka hesaplarını alan olarak açmaktansa ayrı bir tabloda cari hesaba ait onlarca kayıt girilebilir. Nitekim 10 larca banka hesabı olan cariler olacaktır.

Vesselâm.. :)
Cevapla