Ekşi Duyuru

1- evet veritabanını oluşturmak en önemlisi. tabi sadece sorgu yapmak yeterli değil. veriler üzerinde işlem yapmak veritabanına yeni veriler eklemek, silmek, veritabanından veri silmek falan da var. tabi ayrıca programın genelini yazmak. bunun için iyi derecede nesne yönelimli programla bilgisi, algoritma kurma yeteneği ve iyi derecede syntax bilmek gerekiyor. nesne yönelimli programlama mecbur değildir belki ama gerekli bir şey bence. neler yapabileceğinizi biliyorsanız bir program yazarken syntax da o kadar önemli olmaz, yapmak istediğiniz şeyi araştırarak gerekli syntax'ı öğrenebilirsiniz.

not: benim de tecrübem yok da staj yaparken falan gördüğüm şeyler.

merhaba,
aslında hani temel olarak görünen odur. herkesin yaptığı database'deki görece anlamsız verileri anlamlandırıp son kullanıcıya iletmektir. fakat gerçek dünyada kullanıcı istekleri hiçbir zaman bitmediği için gelen veriyi direkt ekrana bastırayım, ekrandan aldığım veriyi direkt db'ye yazayım maalesef olmuyor.
Hani okullarda yapılan projelerde dediğin gibi yapılabilir.

bir de program tasarımı vardır. bunun için kabul görmüş tasarım kalıpları vardır. o kalıplar ve prensipleri kullanarak daha esnek programlar geliştirilmeye çalışılıyor. ve genelde de veritabanı işlemleri için yapılıyor bu. büyük yazılım firmalarında programların bir alt yapıları vardır, kurumsal framework'ler yazılır ve o framework'ler çoğu database işlemlerini otomatize eder. Personeller.GetAll() deyip tüm personelleri çeker misal.
alt yapıyı yapan adamlar haricinde müşteri ile ilgilenip müşteri isteklerini yapan developer arkadaşlar ise hangi veritabanı ile çalışılıyor, veriler webservice'den mi gidiyor, kullanıcı nereden login oldu vs bunlarla ilgilenmez. bu da hız ve genişleyebilirlik sağlar.

Aslında çok uzun bir konu. Yani sen sql sorgusu yazmayı biliyorsun, programdan da sql'e sorgu göndermeyi ve sonucunu almayı biliyorsun program yazarsın ama veritabanı değişirse senin programın komple değişir. ya da bir alan daha eklendiği zaman gidip o tabloyu kullandığın tüm yerlerde değişiklik yapman gerekir vs. ama eğer ki sistem hiç değişmeyecek, en baştan neyin nasıl olacağı kesin olarak belli ise dediğin gibi yapılabilir.

kitap önermeden önce hangi dili öğrenmek istediğine de karar vermen gerek. bence bir dil öğreneceksen java veya c# öğrenmeni öneririm.

@lemmiwinks, teşekkürler. Aslında sorgudan kast ettiğim, bir sql cümleciğinin servera gönderilmesiydi. dolayısı ile silmek-değiştirmek-eklemek de bunun içinde. söylediğinizde kafa takılan bir nokta var, databasei oluşturmak için OOP bilmeye gerek var mı? database için değil, programın arayüzü için gerekli diyorsanız gene benim düşündüğüm sorguyu gönderip sonuçların gösterileceği bir ekran. iş ancak şurada karışıp daha çok programlama becerisi isteyebilir; sonuçlar yorumlanacaksa, grafikte gösterilip etkileşimli bir hal alacaksa vs. ama sadece veri gösterilecekse büyük bir beceri istemeyecektir işin programlama kısmı (doğrumu?)

@barix, teşekkürler. dediklerinize göre işin sıkıntılı olduğu nokta yapının değiştiği zaman ortaya çıkıyor, değişmeyecek bir yapıysa çok da yanlış şeyler yazmamışım sanırım.
Niyetim dil öğrenmek değil, daha genel olarak database yapısı hakkında bilgi sahibi olmak
örneğin: mysql mi mssql mi, oracle nedir. bir yapı oluşturulrken nelere dikkat edilir. çok table oluşturup bunları bağlamak mı yoksa bir table da bir çok veriyi tutmak mı? sorguyu tek satırda yazmak mı yoksa 3-4 ayrı sorgu yapıp bunların sonuçlarını ayrı ayrı göstermek mi? vs.

veritabanları arasındaki farkı bilmiyorum ama dediğin gibi ya ilişkisel veritabanı yöntemi kullanılıyor ya da ilişkisel olmayan NoSql dediğimiz şu sıralar oldukça popüler olan veritabanı yöntemi kullanılıyor.
ama sql,mysql ya da oracle gibi veritabanları ilişkisel verileri tutmak için daha iyidirler. yani müşteriler ve müşterilerine bağlı petleri kaydettiğinde genelde iki farklı tablo yapıp bunları Id'leri üzerinden ilişkilendiririz.
NoSql yaklaşımında Müşteri'yi bir klasör gibi düşünüp içine petlerini de atıyoruz, diğer müşteriye bağlı her şey orada oluyor. sen müşteriyi çekince de uğraşmıyorsun joinlerle falan.

internette nosql ile ilgili de birçok döküman var.

normal sql'de de bazen tablo tasarımında ilişki eğer sistemi çok zorlayacaksa denormalizasyona gidip bazı alanları dediğin şekilde yapabiliriz.

Şu anda gerçek hayatta hybrit sistemler kullanılıyor daha çok. hem ilişkisel hem de döküman tipli veritabanları bir arada kullanılıyor. belki ilerde büyük firmaların da (Oracle,Sun,Microsoft) NoSql çözümleri çıkınca o zaman piyasa ne olur bilmiyorum. ama gelecek nosql'de görünüyor. çok daha hızlı ilişkisel veritabanına göre. google ve facebook da şu anda nosql kullanıyor.

selam,
-sorguyu tek satırda yazmak mı yoksa 3-4 ayrı sorgu yapıp bunların sonuçlarını ayrı ayrı göstermek mi?
*işine işlemine kullanıcı sayısına göre vs gibi parametrelere bağlı olarak değişir.
-çok table oluşturup bunları bağlamak mı yoksa bir table da bir çok veriyi tutmak mı?
*verinin miktarına, database' e sonradan eklenecek kayıtlara göre değişir.
ayrıca bir önceki cevap da geçerlidir.
bence en basit programda bile ilişkili db (relational database) yapısı kullanılmasından yanayım.
-bir yapı oluşturulurken nelere dikkat edilir
*programın ne yapacagına baglıdır cogu zaman. atıyorum: bir şirketin muhasebe programı. burada para hareketleri, ödeme sekilleri, cariler, vs vs bir cok parametre vardır. parametre demiyelim de ne diyelim su anda bilemedim:)
bu kısmı su sekilde özetleyim: ne kadar cok detay varsa o kadar kompleks veri yapısı olur (genelde).
-databasei oluşturmak için OOP bilmeye gerek var mı?
*bu göreceli bir durum, tercihlere bağlı. cok büyük bir firmanın fabrikalarından, satış ağında, muhasebesinde vs gibi bir cok yerinde bu program kullanılıcaksa, program üzerinde birden cok kişi calısıyorsa oop dil yapılarını bilmek zarar getirmez ama kesinlikle fayda getirir.
sorunun basit cevabı ise, db olustururken oop bilmeye gerek yok.
-mysql mi mssql mi, oracle nedir.
*projene göre ve tecrübene göre degişir. artık bircok dil ile bu db sistemlerini kullanabiliyoruz. c# ile mysql i oracle ı, php ile mssql i gibi.
ben mesela php ile mysql, c# ile mssql tercih ediyorum.
mesela bir firmada mssql e para ödemek istemeyen bir patron elemanlarını c# ile çalıstırırken mysql db yi kullandırtabilir.
-oop, database için değil, programın arayüzü için gerekli diyorsanız
*arayüz demek, programların kullanıldıgı kısımdır, butonlar, tablolar, textboxlar, renkler, çizgiler vs.
bunlar web kısmında html css gibi yardımcılarla halledilir. burada oop diye bir varlıktan bahsedilmez.
oop demek en basit deyişle classlar methodlar yardımıyla program yazmaktır(c#, php, java vs. ile).
kafanızın karıstıgını dusundugum yer burası diye tahmin ediyorum.

dilim döndüğünce birşeyler katmaya çalıştım. yanlışlarım varsa affola, düzeltile..

ayrıyetten barix'in son cevabı +1

bilmiyorum sorunuza cevap olurmu ama bende az buçuk bahsedeyim..

- büyük yazılımlar genel olarak katman mimarisi kullanılarak oluşturulur.3 katmanlı bir mimari neler içerir
1-database layer
2-business layer
3-presentation layer

database elbette çok önemli bir katmandır, ama diğer katmanlarıda atlayamayız.. programların genel olarak başlangıcı database tasarlamakla baslar ve gider..

presentation denilen katman kullanıcının karşısına çıkacak katmandır.GUI diye aratırsanız her programlama diline ait araçları bulabilirsiniz.

gelelim business katmanına işte burada nesne tabanlı programlamanın önemi/güzellikleri devreye girer.çok basit bir örnek verelim database ile programınızı bağlamak için connection stringler kullanırız eğer siz business katmanında bir kez tanımlarsanız bunu programınızda herhangi bir yerde bunu çağırıp çağırıp kullanırsınız. ama siz kodunuzun aktif kısmını presentation katmanına yazarsanız ne olur? programda 1000 tane sql sorgusu kullandınız e bi o kadarda conn string kullanmanız gerekebilir. peki yazılımı alan adam ben MsSQL değil Oracle database i kullanmak istiyorum dedi.işte en basit şekliyle business katmanında bir ufak değişiklikle bütün programın conn stringlerini değiştirebiliriz. öbür türlü mantık dışı zaten.

bu aklıma gelen en saçma örnekti, mesela biz kodu nerde kullanırız programın ne kadarı database e ne kadarı derleyiciye yüklenmeli? okul projeleri basittir yapılacaklar önceden bellidir birbirine bağlı 8-10 tane tabloyla işin içinden çıkılır normal yazılımlarda ise alakası bile yoktur.en basit stok takip programlarında bile business katmanına önem verilmeyip formların altına kodları gömüp gömüp yapılan programların geişme şansları neredeyse yok hele ki ERP programlarında vs bu katmanın tasarımı dll lerin önemi o kadar fazladır ki database tasarımından çok daha fazla zaman alabilir.

mesela daha mantıklı bir örnek verelim.satış yapan bir firmayım bir çok elemanım var database e ham veri girişi yapıyorlar fakat benim için güvenlik çok önemli, hata kabul etmeyecek hata yapılsa bile sorumlusunun ortaya çıkacağı bir sistem istiyorum. bir kullanıcı A kaydını girdiğinde başka bir kullanıcı A kaydını okuyabilsin ama üzerinde işlem yapamasın istiyorum.isterseniz siz bir düşünün bunu database ile nasıl yaparım? yoksa business katmanını kullanarak mı kişilere bu hakkı vermeliyim? ikisi de mümkün aslında ama siz database e ne kadar yük bindirmek istersiniz? veya bu yazdığınız program farklı bir firmaya uyarlandığında aynı katmanda ufak değişiklikler yaparak bunları kullanabilirimiyim gibi gibi?

sorularınıza cevap oldumu bilmiyorum ama 3 katmanda çok önemli
1-database- önemli çünkü başlangıç noktanız daha sonra kullanacağınız esnek yapısı olmalı vs vs
2-business- önemli çünkü yeteneğiniz burda ortaya çıkıyor programın kalıcılığı güncellenmesi esnekliği vs gibi katmanlar hep burada
3-presentation- çok çok önemli.. en kolay katman gibi gözüksede hatta öyle olsa bile eğer müşteriye hitap edememişseniz istediğiniz database dizaynını yapın acayip oop mucizeleri yaratın müşteri olmamış der ısınamaz programa artık o program yavaşmı çalışmaz sormu olmaz neler neler..

arkadaşlar cevapları okudum hızlıca, daha sakin bir zamanda bir kaç kez daha okuyacağım üzerinde düşünerek, şu anda hemen birşeyler yazamıyorum diye dikkate almadığım sanılmasın :) tekrar teşekkürler. daha sonra soracağım birşey olursa altına eklerim.

veritabanlarını iyi anlamak için ilişkisel modeli anlamanız lazım(anahtarlar, ilişkiler vs). veritabanı tasarımı ve normalizasyon konularından başlarsanız daha faydalı olacaktır, "verileri tek tabloda tutmak mı çok tabloda tutmak mı iyi" sorusunun cevabı orada.

bahsettiğiniz veritabanı sağlayıcılarına gelince; bunlar kullanıcı yönetimi, güvenlik, sorgu performansı, ek sistem fonksiyonları gibi faydalar sunuyorlar, hepsinin kendine ait avantaj-dezavantajları var.

teorik kısmı öğrendikten sonra iyi bir sql bilgisi kazanıp, onun üzerine veritabanı yazılımlarından biri üzerinde uzmanlaşmak iyidir.

Cok büyük veritabanları icin konuşmuyorum ama ufak veya orta boydakileri doğru modellemek cok zor degil. Acid kuralları ve normalizasyon seviyeleri var, bunları öğrenmen iyi olur. En basitinden ornegin veri tekrarından olabildiğince kaçınıyoruz (OLTP sistemler icin konuşuyorum), bunun gibi kurallar iste. Sonra bire bir - coka çok gibi iliskiler var. Index kavramı var. User ve semaları ve işlevlerini öğrenmen iyi olur. Bir de adını hatirlamamakla beraber transactionlarda olusan hata durumlarına (aynı anda yapılan iki işlemin yarattığı problemler gibi) göre güvenlik seviyeleri oldugunu hatırlıyorum.


Bunlarla bir veritabanını modelleyebilirsin. Daha sonra ileri gitmek istersen isin programlanabilir kısmına girersin, trigger, procedure vs. Sonra da data warehouse olayını kurcalarsin.


Gecmis olsun, database bitti (yok lan şaka). Mevzu genel hatlariyla (benim anladigim) bu.

@zawisza & @samfisher, çok teşekkürler. Bu konular için tavsiye edebileceğiniz bir kitap var mı?

Baya faydası oldu arkadaşlar anlattıklarınızın, tekrar teşekkürler.

kisa, bizim ders kitabını bulup adını versem ağır kaçar. şu rarladığım site iyiydi:
www.2shared.com