Adatbázistervezés. Ti, hogy csinálnátok?
Van vásárló és eladó. Mind a kettőnek regisztrációval kell rendelkeznie.
Érdemes külön venni a regisztrációt és a személyes adatokat?
Például van egy tábla: User(user_name,user_password,user_hash,user_registered,user_permission)
Ez lenne az a tábla, ami majd ugyebár a bejelentkezésre szolgál. Az eleje értelemszerű. user_name az elsődleges kulcs, hiszen abból nem lehet 2 ugyanolyan, a permission meg azt mondja meg, hogy milyen jogosultsága van az alkalmazásban. Tehát jogosultság szinttől függ, milyen funkciókat ér el.
és akkor van a
Customer(customer_id,customer_firstname,customer_lastname,customer_email)
Seller(seller_id,seller_firstname,seller_lastname,seller_email) - Az emailt azért nem a Userbe tettem, mert ezeket az adatokat nem adhatja meg senki, csakis kizárólag olyan aki már regisztált. Szépen kitölti mondjuk a Seller a vevőnek az adatait és az emailre kap egy regisztrációs kódot, amellyel tud majd felhasználót és jelszót megadni. Ha az emailt a User táblába tettem volna akkor a többi adatot muszáj, hogy NULL érték is lehessen, ami nem túl optimális.
Ez szerintetek jó vagy máshogy csinálnátok?
Illetve egy másik kérdés még ehhez kapcsolódoan. A vásárlókhoz cégek tartoznak, egy vásárlónak több cége is lehet. tehát csinálok egy Company táblát Company(company_id,company_name..stb). A kettőt nem túl optimális összekapcsolni, mert akkor ha egy vásárló 3 céghez tartozik és mondjuk a cég elsődleges kulcsát adok meg a felhasználóhoz akkor a felhasználó a táblában többször fog szerepelni. Viszont vice-versa is. Itt arra gondoltam csinálok egy segét táblát, amely csak a Customer,Company táblák elsődleges kulcsát tartalmazza. Csak itt nem tudom, hogy a kapcsolat elvileg közöttünk N - M nem? Hiszen egy ember több céghez is tartozhat és egy cég is több emberhez.
válasza:A User és a Customer tábla összefügg egymással, de nem látok olyan adatot, ami alapján össze lehetne kapcsolni őket. Az User-be is kellene egy user_id, ami egyezik a customer_id-vel vagy valamilyen más adat.
"Itt arra gondoltam csinálok egy segét táblát, amely csak a Customer,Company táblák elsődleges kulcsát tartalmazza."
Igen, ez a megoldás.
"Hiszen egy ember több céghez is tartozhat és egy cég is több emberhez."
És ez miért probléma? Eltárolod a segédtáblában a (customer_id, company_id)-ket (pl.: (1,2), (1,14) -- tehát, hogy 1-es customer két company-ben is dolgozik), innentől kezdve az alkalmazás fejlesztőéjé a feladat, hogy a kedves customer csak olyan company-t választhasson ki a rendelés leadásakor, amihez van rekordja (tehát idegen company nevében ne adhasson le rendelést).
Egyébként nem tudom milyen szinten művelitek a témát, de első lépés az egyedkapcsolat-modell (entity-relationship model) kellett volna, hogy legyen, az megvan? Abból tök egyszerűen fel lehet írni a táblákat, majd következő lépés a normalizálás.
Köszönöm. Igen Userbe is lehetne egy user_id, de gondoltam arra, hogy ugyebár a felhasználónév egyedi és ez is lehet elsődleges kulcs. Nem lehet két egyforma. De lehet lesz egy id auto increment int-el, mert "szebben" néz ki.
Azért nem akartam ER modellel, mert úgy átláthatatlan lenne így rajzolgatva sajnos. Sok adat van és mindig jön valami új és abban javítgatni, törölgetni hosszabb idő. Excel táblába szedtem össze nagyjából mik lesznek és utána MS Visioba nem ER modelben, hanem EF-ben, így könnyebben szerkeszthető és a kapcsolatokat is szebben lehet látni.
További kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!