Felhívás habrahabr számítógépekre és az internetre
És mi más, véleménye szerint meg kell szabadulnia az olvasási státusztól az agyon?
A probléma lényege ez:
Jelenleg egy online áruházat (számítógépek, alkatrészek, hordozható számítógépek stb.) Adok hozzá.
Az adatbázis struktúrájának átgondolása nem egészen alaposan történt, tk. ez az első többé-kevésbé nagy projekt.
A kezdeti szakaszban, amíg a bázis csak laptopokhoz, netbookokhoz, stb., Úgy tűnik, minden rendben van. De akkor felmerült a kérdés, hogy a készletek és hasonló áruk hozzáadására kerül sor, mert laptopok és hasonló tulajdonságok száma (a táblázatban szereplő mezők)
24 + mindegyik típusú tartozék esetében 5-6 egyedi egyedi minden attribútum típushoz, azaz a folyamat során a tábla szélessége szélesebb, mint és toleráns, de:
A probléma megoldásához kerestem az internetet. Nos, valójában magamnak, azonosítottam az adatbázis létrehozásának két alapvető módját:
1) Egy táblázat hagyatéka (STI) - ez a szerkezet magában foglalja egyetlen táblázatot az összes termék mindenféle, és ahogy az várható volt, hogy növekedni fog a szélesség és a legtöbb területen az lesz NULL-evymi. Úgy tűnik, hogy az áruk száma nem haladhatja meg az 5-6 ezret (az előzetes előrejelzések szerint). egy 40-50 mezővel és 5000-6000 sorral rendelkező táblázat néhány pillanat alatt gond nélkül visszatéríti a szükséges értékeket. És igen, ez a struktúra relációs adatbázis, amely számomra személyesen kinyilatkoztatás volt.
Itt az "admin" -ben, amikor árut adok egy nagy asztalhoz, csak megadom, mely mezőket kell kitölteni, a többi automatikusan NULL lesz.
2) Entity-Attribute-Value (EAV) - az áruk három táblába való felosztása:
- Entity - Táblázat, amely információkat tárol minden termékről, de 4-5 fő oszlop formájában (ugyanaz mindenki számára). Mint például: id, név, ár, gyártó és így tovább.
-Attribute-tárolja az egyes terméktípusok attribútumainak teljes listáját az űrlapon (id_attribute, attr_value) azaz. ugyanaz a hosszú asztal, mint megértettem. Ha például 1000 laptop lesz 15 egyedi paraméterrel - ez 15 000 sor (nem annyira, de ez)
-Az érték olyan tábla, amely összekapcsolja az entitást és az attribútumot idegen kulcsokkal, az űrlap párosításával (id_product, id_attribute) azaz. Mérete kicsit nagyobb lesz, mint az Attribútum táblázata.
Összesen: a raktáron elhelyezett árukról szóló információk megtalálhatók, amelyeket az adatbázisban szereplő indexek "ostobán" tárolnak. De ismét, miután elolvasta a tyrnetah-t, a következő mínuszokat választotta ki magának:
-A kérések nagyon (nagyon jó számomra) nagyszerűek lesznek. Az áru kártyájának megjelenítéséhez be kell szúrnia az INNER JOIN-ba
-A szerkezet összetettsége, és ennek következtében a zavartság a motor részéről (ezt írom a PHP-ben), ismét, az összes redoing-on és így tovább.
-És általában: ez a játék érdemes a gyertyát. Olyan sok áruval érdemes ilyen módon torzítani?
Ez valójában azt akarta mondani, és mit kérdeznie a programozás elméjében.
Köszönjük figyelmét!
A második lehetőség meglehetősen működőképes és könnyen használható, a legfontosabb az objektumok szerkezetének és tulajdonságainak helyes megválasztása, figyelembe véve az áruk egész sorát, így az új típusú áruk hozzáadása nem vezet az adatbázis szerkezetének megváltozásához.
Ha minden rendben van, akkor csak az adatok tartalmának, minőségének és relevanciájának figyelése szükséges.
Köszönjük, hogy válaszolt!
Jelenleg valami olyasmit próbálok végrehajtani:
Van egy táblázat a főbb jellemzők típusával: típusok (id, cím)
van egy táblázat, ahol a jellemzők értékei tárolódnak: type_list (id, id_type, value)
és az áru táblázatban (igen, ez mindenki számára megegyezik), ezen jellemzők területén importálnak külföldi kulcsokat az asztalról type_list
Meghívás habrahabra
Annak érdekében, hogy jobban megértsük, mire van szükségünk, ezt a funkcionalitást a rendszer felhasználójának állásából tekinthetjük meg. Képzeld dolgozik a webes formában (vagy benézett egy másik boltban), ami megy kérelmet, hogy milyen szűrők vannak kulcsfontosságú lefoglaló nagy mennyiségű adat alapján a különböző termékek (akkor megy külön könyvtárakban vagy típusú mezők).
Tudja meg, milyen általános lekérdezések lehet minden formája (a kimenő termékek listáját a különböző területeken, bizonyos pechati-).
A szerkezet meglehetősen logikus, ha jól értettem, hogy ez valamiféle típusú:
2 | 1 | Tartozékok - javításhoz stb.
3 | 1 | tartozékok
4 | 2 | Netbookok
5 | 2 | tartozékok
A gondolatmenet jó, de fontos elképzelni egy igazán működő üzleti folyamatot, sok árnyalatot és vas igényt nyit meg, amelyet azonnal jobban figyelembe kell venni, hogy az egész szerkezetet és tartalmat ne ássák.
Egy konkrét megvalósításról nem tudok sokat segíteni, mert Nem tudom a részleteket, és nem vagyok különleges SQL-ben, de dolgozom a különböző rendszerek adatbázisaiban, és mindent láttam.
Csak két nappal később elaludtam és felébredtem ezekkel a gondolatokkal a fejemben)
Munkára ülök, ezért este este elkezdek csinálni valamit. eddig megállt a "frissítés előtti" előtti verzióban:
1. táblázat - áruk (id, cím, márka, ár, img ..) tartja a tájékoztatást az összes termék, de csak a főbb területeket, amelyek az egyes elemeket.
2. táblázat - notebook (id, id_good, param1, param2, param3) tartja a tájékoztatást a laptopok kazhdoogo nouta - egy sort id_good - áru idegen kulcs táblázat;
Talán - ez a legnagyobb, amellyel jelenleg képes vagyok kiüríteni magam). nekem prof. a programozó még messze van, és az időzítés szűkös. és még mindig rám van a PHP bevezetése, az áruház adminisztratív kezelőfelülete a funkciók széles választékával, a weboldal tervezésével és más finom ízekkel, mint például az árucikk szűrője mind a konnektoron, mind stb.