Uh, ja na ovo sto je zlatni poslao imam gomilu zamerki. Ukratko:
- Customer tabela treba da sadrzi samo ID, username i password, jer se to koristi za logovanje i na svim drugim mestima. Detalji idu u odvojenu tabelu, da rasterete bazu od citanja i mozda slanja nepotrebnih podataka u svakom upitu. Ako mislite da mozete da uradite SELECT ID, Username, Password, razmislite ponovo: Osim ako nemate covering index, db engine ce citati ceo red sa diska. Kad dodje do milion korisnika, pocece da boli.
- Osobine product-a treba da idu u odvojenu tableu, uz trecu veznu tableu koja vezuje svaki produkt sa osobinama. Onda mozes da radis i obrnuti search, tipa, daj mi sve products gde je boja "crvena". Dodatno, ako u tabeli ima i food_flavor i isbn_number, onda ne gine gomila null-ova u tabeli.
- Sta je koj' djavo parent_product ? Ako trebaju kategorije, to ide u odvojenu tabelu.
- Mora da postoji i Payment, a ne samo payment method. Dodatno, znam da je kao ilustracija, ali nikad, NIKAD ne ide card_number u bazu. Procesiranje placanja radi procesor, vi ne cuvate podatke o korisnikovoj kartici, samo ID iz payment procesora za refund. Da bi cuvali i procesirali kartice morate da imate PCI compliance, plust jos trista cuda - ne zelite to. Zapravo, payment_method je mozda i suvisna, ne cuvate podakte lakse vam je. Sta ce vam "payment method" ako je on "platio uplatnicom"?
- U product price ide i polje JE_AKTIVNA, plus index koji kaze da je kombinacija product_ID + Je_aktivan =1 unique. Onda izvlacenje cene za ID ide po tom indexu, a ne po WHERE DATUM najveci. Kad bude par miliona redova u tabeli, ubrzanje ce biti za red velicine, minimum.
Kad razrezis ove boljke, lepo se vratis za knjigu, prva, druga, treca nf, boyce-code i to je to.
Please do not feed the Trolls!
Blasphemy? How can I blaspheme? I'm a god!'