Şu tür değişiklikler daha iyi olur gibi
5 Mayıs 2013 01:48 tarihinde Levent SARI yazdı:
> Arkadaşlar Merhaba,
> Database konusunda pratik yapabilmek için kendime örnek bir uygulama
> yazmak istiyorum.
> Ancak biliyorum ki database tasarımı çok önemli bir konu ve önemli olan
> iyi bir database t
6 Mayıs 2013 01:44 tarihinde Bugra Sari yazdı:
> İlave olarak;
>
> uyeId ve kitapId alanları gereksizdir. Üye tablosu için uyeTc, kitap
> tablosu için kitapBarkodNo, primary index olarak tanımlanabilir.
>
Barkod ya da ISBN'i olmayan kitaplar da var.
--
*Görünenler*, *gerçek olsaydı bilime* ger
2013/5/7 Levent SARI
>
> ( http://dbpatterns.com/ açılmıyor şuan açılınca oraya da ekleyeceğim.)
>
>
Selam,
Aksilik. Sunucu Hetzner'de, bugün sunucuya erişemedik. Donanımsal problem
olabilirmiş. Hala yanıt bekliyoruz.
--
Fatih ERİKLİ
http://www.fatiherikli.com
_
Öncelikle konu ile ilgili fikir beyan eden herkesin yüreğine sağlık.
Kütüphane Otomasyonu tarzı bir şey daha önce hiç yazmadım.
Çalıştığım kurumlarda kod yazdığım uygulamalarda ise database ler
sürekli tasarlamış halde gelmekde idi.
O yüzden tek başına sıfırdan bu tarz bir iş ile uğraşıp pratik
Haklısınız. Güvenlik açısından önemli verilerin veritabanında tutulması
uygun değildir. En doğrusu her üyeye bir üye numarası verip sorgulama
yaparken üye numarası istenmesidir.
Ama sorgulama yapmak için TC kimlik numarası girilmesi istenebilir. (Üyeler
kendilerine verilen numarayı sürekli akıllar
2013/5/6 Bugra Sari :
> uyeId ve kitapId alanları gereksizdir. Üye tablosu için uyeTc, kitap tablosu
Ama bence daha onemili problem bir kitap icin tc istemek. Tckimlikno
toplamak biraz riskli ve gerekli de degil.
Bunun yerine bence baska unique birsey bulun. Eposta mesela..
--
--
Ali Rıza Keleş
Selam,
Veritabanı modelleri üzerinde pratik yapmak için dbpatterns'ı
kullanabilirsiniz. Bu sayede çalıştığınız modeli birisi görüp önerilerini
yazabilir, ya da fork'layarak ben olsaydım şöyle yapardım diyebilir.
http://dbpatterns.com
--
Fatih ERİKLİ
http://www.fatiherikli.com
_
Kütüphane de ki kitap tablosuna birde date alan eklemenizde fayda var,
kitabı bir contact a assignee ettiğinizde o kolona o anın tarihini çekip
yazarsanız, Last modfy date gibi gibi bir alan tutmuş olursunuz. Kalifiye
olur. Zaten o tablolar daha dağ gibi büyür sizin hayal gücünüze kalmış ama
başlan
İlave olarak;
uyeId ve kitapId alanları gereksizdir. Üye tablosu için uyeTc, kitap
tablosu için kitapBarkodNo, primary index olarak tanımlanabilir.
5 Mayıs 2013 09:29 tarihinde M.Dumlupinar yazdı:
> Üye, Kitap gibi tablolarınızdaki alanların başlarına tablo isimlerini
> eklemeniz doğru değ
Üye, Kitap gibi tablolarınızdaki alanların başlarına tablo isimlerini
eklemeniz doğru değil. Zaten işlemlerde tablo isimlerini ayırıcı olarak
kullanacaksınız, tekrar terkrar yazmak OKUNURLUĞU azaltacaktır
Örnek;
SELECT U.* FROM UYELER AS U;
SELECT K.ADI, K.BARKOD, I.ALINMA_TARIHI, I.KONSINYE F
Yiğit Bey'e aynen katılıyorum. Ancak, tanımladığınız modelden biraz daha
fazlasının olmasını tavsiye ediyorum. Şu örnekteki olabilir mesela:
http://www.databaseanswers.org/data_models/library/index.htm
Daha fazlası için: http://www.databaseanswers.org/data_models/ (14. Başlık)
Selamlar,
Nuri Akma
işlerin sarpa sardığı bölümü göremedim şu anki tablo yapısı gayet basit ve
işinizi görebilecek durumda. performans için üye tablosunda
alinan_kitap_sayisi gibi bi kolon ekleyip üye kitap aldığında 1 arttırarak
üyenin aldığı kitap sayısını yazabilirsiniz diğer türlü işlem tablosuna da
sorgu atmanız
12 matches
Mail list logo
