objednávky-bez registrace

nightrider
poznámka mimo: správně (zprávy jsou třeba v televizi), shoda (schody jsou ve schodišti). To ostatní jsem už ochotný tolerovat :-)

K tématu:
No a proč by si klient nemohl zadat nějakou výchozí adresu?

co když klient původní objednávku chtěl odeslat na adresu rodičů?
No a? Adresa musí stejně být vázaná na objednávku (těžko můžete při změně adresy přepsat staré faktury, nehledě na to, že by nešlo udělat dvě objednávky na různé adresy), takže kde je problém?

nightrider
U nakupu bez registrace bych klidne zakaznika nechal pokazde vyplnit adresu, kontakty atd znovu s tim ze mu nabidnu registraci. Pokud registraci nevyuzije, priste bude muset vyplnit udaje znovu. Proc se snazit udelat programy chytrejsi nez uzivatel, nakonec jsou z toho jen problemy. Tobe odpadne reseni jak udelat update databaze, a uzivateli starosti s tim co delat, kdyz mu system cpe nejakou adresu, kterou ani treba nezna.

nightrider
„pokud adresa souhlasi, tak se vkladaji pouze objednavky pod starou registraci.“
registrace/bez registrace je v tom trochu hokej. Kazdopadne to abys nemel v tabulce duplikovane zaznamy resi normalizace databaze. Neni preba do toho cpat e-mail. Nic vic bych neresi.

nightrider
„Db jako taková neumí porovnávat data nebo jo?“
Zalezi na tom jak s ni nakladas, treba unique index porovnava data. Vetsinou se to osetruje v aplikacni logice, ale neni problem si napsat funkci treba v MySQL a vkladat data pres ni. Koukni na tenhle clanek, tam jsou celkem pekne popsany normalove formy.

nightrider
System mu nic necpe udelal jsem to tak ze pokud adresa souhlasi, tak se vkladaji pouze objednavky pod starou registraci.
Pod jakou registrací, když je to bez registrace?

Už se taky nějak ztrácím- co se vlastně řeší za problém?
Pokud nechci registrace, teoreticky by mi v základním případě stačila jenom jedna tabulka pro objednávky (nepotřebuju ani tabulku pro uživatele), plus vazební tabulka mezi objednávkou a zbožím.
Nevím, co je tu k řešení na adrese.

Základní hrubá tabulka pro objednávky: ID objednávky (primární klíč) | e-mail | jméno | adresa | ...
...pro začátek by něco takového stačilo. V další fázi se můžu začít vrtat v tom, že databáze je v první normální formě, ale není ve druhé, protože minimálně mezi jménem a e-mailem existuje závislost, kterou tabulka nezachycuje, dál se můžu hrabat v tom, že při jemnějším rozlišení není adresa atomický údaj... a tak dál.

Tohle je právě ta normalizace.

Joker
„pro začátek by něco takového stačilo. V další fázi se můžu začít vrtat v tom, že databáze je v první normální formě, ale není ve druhé“
Databaze by se mela uz navrhovat normalizovana, pozdejsi normalizace sebou prinasi jen spoustu problemu a prepisovani hromady kodu.