Akár olyan adatbázissal dolgozik, amely több száz rekordot vagy több millió rekordot tárol, a megfelelő adatbázis-tervezés mindig fontos. Nemcsak hogy megkönnyíti az információ visszakeresését, hanem egyszerűsíti az adatbázis bővítését a jövőben. Sajnos könnyű néhány csapdába esni, ami a jövőben megnehezíti a dolgokat.
Az adatbázis normalizálásával kapcsolatban teljes könyvek vannak írva, de ha egyszerűen elkerüljük az itt bemutatott gyakori hibákat, jó úton haladunk a jó adatbázis-tervezéshez.
Adatbázis hiba # 1: Ismétlődő mezők egy táblázatban
A jó adatbázishoz való alapvető szabály az, hogy ismételje az ismétlődő adatokat, és ezeket az ismétlődő oszlopokat saját táblájukba helyezze. A tábla mezők ismétlődése gyakori azok számára, akik a táblázatok világából származtak, de a táblázatok általában tervszerűen laposak, az adatbázisoknak kapcsolódniuk kell. Olyan, mintha 2D-ről 3D-re megyünk.
Szerencsére az ismétlődő mezőket általában könnyű észrevenni. Nézzétek meg ezt a táblázatot:
| Rendelés azonosító | Termék1 | Termék2 | Product3 |
| 1 | Játékmacik | Jelly bab | |
| 2 | Jelly bab |
Mi történik, ha egy megrendelés négy terméket tartalmaz? A táblázathoz további mezőt kell hozzáadni, hogy több mint három terméket támogassunk. Ha pedig az asztal köré építettünk egy ügyfélalkalmazást, hogy segítsen az adatok bevitelében, módosítani kell az új termékmezővel. És hogyan találjuk meg az összes rendelést a Jellybeans-el a sorrendben? Arra kényszerülnénk, hogy a táblázatban szereplő összes termékmezőt egy olyan SQL utasítással lekérdezzük, amely a következőképpen néz ki: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' VAGY Product2 = 'Jelly Beans' VAGY Product3 = 'Jelly Beans'.
Ahelyett, hogy egyetlen táblázatot adnánk, amely összegyűjti az összes információt, három táblával kell rendelkeznünk, amelyek mindegyike különálló információt tartalmaz. Ebben a példában szeretnénk megrendelést tartalmazó táblázatot, amely magában foglalja a megrendelést, a terméktáblázatot az összes termékünkkel és a ProductOrders táblagépet, amely összekapcsolta a termékeket a megrendeléssel.
| Rendelés azonosító | Ügyfél-azonosító | Rendelés dátuma | Teljes |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Termék azonosító | Termék | Számol |
| 1 | Játékmacik | 1 |
| 2 | Jelly bab | 100 |
| ProductOrderID | Termék azonosító | Rendelés azonosító |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Figyeld meg, hogy az egyes táblázatoknak megvan a saját egyedi azonosítójuk. Ez az elsődleges kulcs. A táblázatokat az elsődleges kulcsérték használatával kapcsoljuk össze egy másik táblában idegen kulcsként. További információ az elsődleges kulcsokról és az idegen kulcsokról.
Adatbázis hiba # 2: Táblázat beágyazása a táblába
Ez egy újabb gyakori hiba, de nem mindig tűnik ki olyannyira, mint az ismétlődő mezők. Adatbázis tervezésénél ügyelni kell arra, hogy a táblázatban szereplő összes adat önmagára hivatkozzon. Olyan ez, mint a gyermeki játék, ami megkülönbözteti a különbséget. Ha van banánja, eper, barack és televízió, a televízió valószínűleg valahol máshol van.
Ugyanezek a sorok, ha van egy asztal az eladók, az összes információt az adott táblázatban kell kifejezetten az adott értékesítési személy. Minden olyan extra információ, amely nem egyedi az adott értékesítési személy számára, valahol máshol is szerepelhet az adatbázisban.
| SalesID | Első | Utolsó | Cím | Telefonszám | Hivatal | OfficeNumber |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | Kovács | 504 2nd Street, New York, NY | (211) 122-1821 | New York (kelet) | (211) 855-4541 |
| 3 | Joe | Plébánia | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Bár ez a táblázat úgy néz ki, mintha az az egyes értékesítőkhöz tartozna, ténylegesen van táblája a táblázatban. Vegye észre, hogy a "Office és OfficeNumber" megismétli az "Austin Downtown" -ot. Mi történik, ha az irodai telefonszám megváltozik? Egy adatcsomagot frissíteni kell egy adatcserére, ami soha nem jó dolog. Ezeket a mezőket át kell helyezni a saját táblájukba.
| SalesID | Első | Utolsó | Cím | Telefonszám | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | Kovács | 504 2nd Street, New York, NY | (211) 122-1821 | 2 |
| 3 | Joe | Plébánia | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Hivatal | OfficeNumber |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | New York (kelet) | (211) 855-4541 |
Ez a fajta felépítés lehetővé teszi, hogy további információkat adjon hozzá a Hivatal asztalához anélkül, hogy rögtönzött rendetlenséget okozna az értékesítési személy táblájában. Képzeld el, hogy mennyi munkát kellene követnie az utcanevet, a várost, az államot és a postai irányítószámot, ha az összes információ az értékesítési asztalnál volt!
Adatbázis hiba # 3: Két vagy több információ beillesztése egy mezőbe
Az irodai adatok beillesztése az értékesítési személy táblájába nem volt az egyetlen probléma az adatbázisban. A cím mező három információt tartalmazott: az utcát, a várost és az államot. Az adatbázisban lévő minden mezőnek csak egy darab információt kell tartalmaznia. Ha egy mezőben több információ található, akkor nehezebb információt kérni az adatbázisban.
Például, mi lenne, ha lekérdeznénk az Austin összes értékesítőjén? A címmezőn belül kell keresnünk, ami nemcsak nem hatékony, hanem rossz információkkal is szolgálhat. Végtére is, mi történik, ha valaki az Oregon-i Portland-i Austin utcán élt?
Az alábbi táblázatnak kell lennie:
| SalesID | Első | Utolsó | Cím 1 | Cím 2 | Város | Állapot | Postai irányítószám | Telefon |
| 1 | Sam | Elliot | 118 Fő St | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | Kovács | 504 2. sz | New York | NY | 10022 | 2111221821 | |
| 3 | Joe | Plébánia | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Van itt néhány dolog, amit meg kell jegyezned.Először is, a "Cím1" és a "Cím2" látszólag az ismétlődő mezők hibájába esnek.
Azonban ebben az esetben olyan különálló adatokra utalnak, amelyek közvetlenül kapcsolódnak az értékesítési személyhez, nem pedig egy olyan ismétlődő adatsorhoz, amely a saját táblájában megy.
Továbbá, mint elkerülendő bónusz hiba, észrevehetjük, hogy a telefonszám formázása le van-e húzva az asztalról. Ha lehetséges, kerülje a mezők formátumának tárolását. A telefonszámok esetében többféle módon írhatnak telefonszámot: 215-555-5858 vagy (215) 555-5858. Ez egy keresőszemélyt keresne telefonszámával, vagy ugyanazon a körzetszámmal rendelkező ügyfelek keresését nehezebbé teheti.
Adatbázis hiba # 4: Nem megfelelő primer kulcs használata
A legtöbb esetben egy automatikus növekményes számot vagy más generált számot vagy alfanumerikus kódot szeretne használni az elsődleges kulcs számára. Kerülje el az elsődleges kulcs tényleges adatait, még akkor is, ha úgy hangzik, mintha egy jó azonosítót eredményezne.
Például mindegyikünknek megvan a saját egyéni társadalombiztosítási száma, így a munkavállalói adatbázis társadalombiztosítási számának használata jó ötletnek tűnhet. De míg ritka, lehetséges, hogy még egy társadalombiztosítási szám is megváltozik, és mi soha nem akarjuk, hogy az elsődleges kulcsunk megváltozzon.
És ez a probléma a tényleges információk kulcsfontosságú értékekként történő használatával. Ez megváltozhat.
Adatbázis hiba # 5: Nem Naming egyezmény
Ez nem feltétlenül nagy dolognak tűnik, amikor először elkezdjük megtervezni az adatbázist, de miután eljutottunk az adatok lekérdezéséhez az adatok lekérdezéséhez, az elnevezési konvenció segít a térinformációk megjegyzésekor.
Képzeljük csak el, mennyire nehezebb lenne ez a folyamat, ha a neveket FirstName, LastName egy táblában és first_name, last_name egy másik táblában tároltuk.
A két legkedveltebb elnevezési konvenció a terepen lévő minden szó első betűjével, vagy az aláhúzás segítségével elválasztja a szavakat. Előfordulhat, hogy egyes fejlesztők is kihasználják minden szó első betűjét, kivéve az első szót: firstName, lastName.
Azt is el szeretné dönteni, hogy egyedi tennivalókat vagy több táblázatneveket használ. Rendelõ asztal vagy rendelési táblázat? Ügyféltábla vagy ügyfelek táblája? Ismét nem akarsz megragadni a rendelési táblázattal és az Ügyfelek táblával.
Az Ön által választott elnevezési egyezmény nem olyan fontos, mint az elnevezési egyezmény tényleges megválasztásának és ragaszkodásának folyamata.
Adatbázis hiba # 6: Nem megfelelő indexelés
Az indexelés az egyik legnehezebb dolog, hogy helyes legyen, különösen azok számára, akik az adatbázis kialakításában újak. Minden elsődleges kulcsot és idegen kulcsot indexálni kell. Ezek az összekapcsolási táblák, tehát index nélkül nagyon rossz teljesítményt fognak látni az adatbázisból.
De ami túl gyakran hiányzik a többi területen. Ezek a "WHERE" mezők. Ha gyakran szűkítené a keresést a WHERE záradék valamely mezőjével, akkor azt szeretné, ha egy adott indexet hozna létre ezen a mezőn. Azonban nem szeretné túlságosan indexelni az asztalt, ami szintén sérti a teljesítményt.
Hogyan döntenek? Ez az adatbázis tervezésének művészete. Nincsenek kemény határok, hogy hány indexet kell elhelyezni egy asztalra. Elsősorban bármely olyan mezőt szeretne indexelni, amelyet gyakran egy WHERE záradékban használnak. További információ az adatbázis megfelelő indexeléséről.
