Új hozzászólás Aktív témák
-
modder
aktív tag
Hello
W3DBSMGR (5.22.1.18) Error 8520
google keresés:
http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Ahu%3Aofficial&hs=W9y&q=W3DBSMGR+(5.22.1.18)+Error+8520&btnG=Searchelső találat:
http://simple-pc-help.com/support/error_8520.html?t202id=231&t202kw=error%208520&gclid=CL_Dn87HypQCFRg1Zwod-iUWlglehet hogy nem
pervasive sql 9
specifikus probléma.[ Szerkesztve ]
-
modder
aktív tag
Ja, nem jó.
A user_hirdetés kapcsolótáblában inkább user_id és hirdetes_id-nak kellene szerepelnie.
De teljesen fölösleges is a kapcsolótábla, mivel ez egy one-to-many kapcsolat a user felől a hirdetések felé: egy user több hirdetés. így elég csak user_id-t tárolni a hirdetés táblában, mit te hirdető_id-nak nevezel. Kapcsolótáblát csak a many-to-many relációknál használnak.
... Esetleg akkor, ha a kapcsolatnak külön tulajdonságot rendelsz, ami a kapcsolatra vonatkozik. akkor viszont érdemes egy unique constraint-et tenni a kapcsolótábla hirdetés_id mezőjére, hogy elkerüld, hogy egy hirdetést véletlenül több felhasználóhoz kapcsolj
Hirdető táblában nem kell a hirdetés_id. akkor minden hirdetőhöz csak egy hirdetés tartozhatna. a hirdető<-->hirdetést megadja a hirdetés tábla hirdető_id-ja.
teljesítményben annyit tudsz javítani, hogy indexeld a keresésben használt mezőket, vagy ha egyszerre több mezőt is használsz egy-egy fajta keresésben, akkor indexet megadhatsz több mezőre is.
Ha pedig többmillió rekordod lesz meg brutál forgalom meg istentudja, akkor táblaparticionálás. ez a két legfontosabb dolog teljesítményben[ Szerkesztve ]
-
#1363
modder
aktív tag
Sk8erPeter
#1362
modder
aktív tag
válasz
Sk8erPeter
#1362
üzenetére
Ehhez pedig én is még annyit hozzátennék, hogy az access-t, mint platformot vagy toolt amire alkalmazást lehet írni, tényleg felejtsd el. arra viszont jó, hogy gyakorold vele az SQL-t. Ha pedig az SQL-t már nagyjából ismered, a szemlélet és a szintaxis már nem annyira különbözik az egyes relációs adatbázisoknál. persze mindig vannak bonyolultabb esetek, amikor mélyebbre kell ásnia magát az embernek egyes adatbázis gyártók megoldásaiba.
Ha pedig azt mondod, hogy gyakorolni szeretnél, arra én is inkább a MySQL-t vagy az MS SQL express-t ajánlom, mert azok legalább rendes, "production" környezetben használt adatbázisok, és ingyenesek. -
modder
aktív tag
válasz
pittbaba
#1594
üzenetére
érdekes probléma, és ebből nem tudjuk meg, hogy miért lassú.
Azt mondod gps koordináták alapján akarod kiszedni, hogy melyik megállóban áll. Be tudnád írni a pontos lekérdezést, és egy-egy sor példát a három táblából? Feltételezemm, hogy a telefon nem pont ugyanazt a gps koordinátát fogja visszaadni, amit a táblában tárolsz, tehát ilyen kisebb-nagyobb összehasonlításokat végzel, ami elég költséges lehet.
Plusz nem értem, hogy miért nehéz bármit is változtatni az eredeti formátumon. Gondolom úgy működik, hogy az ember wifi közelben updateli az adatbázist, ekkor akármilyen transzformációt csinálhatsz rajta, majd úgy mented el az SQLite adatbázsiban, ahogy akarod. Keresésénél kell gyorsan működnie, nem updatenél
[ Szerkesztve ]
-
modder
aktív tag
válasz
pittbaba
#1596
üzenetére
kíváncsiságból én is feltettem notin mysql-be betöltöttem, és elkezdtem futtatni a lekérdezésedet. Nem tudtam végigvárni
1) Ez egy viszonylag normalizált adathalmaz, de nem feltétlenül lesz jó keresések szempontjából
2) mivel az adatbázis csak lekérdezésre lesz használva, simán megcsinálhatod, hogy létrehozol különböző táblákat, amik a keresést megkönnyítik: a relációkat denormalizálod, azaz egy adat, és az adatok közötti függőségek többszörösen lesznek letárolva. Ezzel azt nyered, hogy gyorsabban fogsz tudni keresni.
A "csak lekérdezéseket" azért emeltem ki, mert így nem kell majd azzal foglalkoznod, hogy az újonnan beszúrt adatok elrontják-e az adatbázist. Például az egyik táblába beszúrod, de a másikba elfelejted, satöbbi.3) Igen, az indexelés, amit már említettek. A megálló nevére rá kell tenned egy indexet mindenképpen, ha így keresel, viszont nem hiszem, hogy SQLiteban van fulltext index: azaz szövegen belüli indexelés. Mivel LIKE %valami%-kal keresel, mindenképpen be fogja olvasni a rekordot, belemászik a szövegbe, és rákeres a szövegrészletre, szóval hiába indexeled, semmit nem fog érni. Max akkor, ha tökéletes egyezést keresel.
Többi indexelés:
-- stops.stop_id elsődleges kulcs, állítsd be annak, vagy tegyél rá egy indexet;
-- stop_times.trip_id -ra és stop_times.stop_id -ra külön-külön tegyél egy indexet;
-- trips.trip_id -ra tegyél egy indexet
azért ezekre, mert ezek azok az oszlopok, amik mentén te joinolsz, és ezek által az id-k alapján fog keresni az adatbázis.ezekkel az indexekkel nekem a keresés 3 másodperc alatt lefutott laptopon. telefonon nem tudom milyen lesz...
Konkrétizálva:
Te most azt csinálod, hogy rákeresel a megálló nevére, majd megálló id alapján groupolod egy másik tábla oszlopa alapján, hogy ha egy utcában több megálló is van, azokat is megkapd. Ezzel még csak a megállókat találod meg, de nem nyersz információt az áthaladó trippekről. Az információ amire valójában szükséged van az a megálló_neve, megálló_id.Ehhez képest te összejoinolod mind a három táblát. tegyük fel, hogy a stops táblából megtalálja a megfelelő sorokat amik pl az Örs vezér tere-re stimmelnek, ez lesz pl 10 sor, akkor szépen elkezdi végigkeresni a másik két táblában a hozzájuk tartozó sorokat, de a trip_id és a departure_time nem fog információt hordozni, mert groupoltad az egészet stop_id alapján, szóval egy megállóhoz csak egy trip_id-t fog kiadni... szóval ez így teljesen rossz.
Ami neked kell ebben az esetben:
SELECT stop_name,stops.stop_id FROM stops WHERE stops.stop_name LIKE '%Örs%' GROUP BY stops.stop_idViszont te GPS alapján akarod megtalálni, ez is jó lesz. Indexelned kell a stop_lat és stop_lon mezőket, és lekérdezed úgy, ahogy írtad. Csak a megállót! Akkor felhasználó kiválasztja a pontos megállót, így az átmenő trip-eket már csak az alapján kell keresned (fölösleges a közelben lévő megállókon átmenő tripeket is megkeresni).
Átmenő trippek:
SELECT * FROM `stop_times` WHERE stop_times.stop_id = valami and `departure_time` > "06:00:00"Optimalizálás:
Visszatérve ahhoz, amit a legelején írtam a denormalizálásról. Nekem ezek a lekérdezések a belinkelt adathalmazon elég gyorsan lefutottak, de telefonon lehet, hogy más lesz a helyzet. Először próbáld ki rendesen indexekkel, hogy milyen eredményeket kapsz, és ha nem jók, akkor el lehet kezdeni szétdarabolni pl. a stops táblát 10 külön táblára, ezt hívják particionálásnak. Feltéve, hogy az SQLite van olyan intelligens, hogy nem olvassa be a memóriába az egész adatbázis fájlt, hanem beindexeli hogy melyik tábla hol kezdőik a fájlban, ezzel rendesen meg tudod gyorsítani a dolgokat.Például szétdarabolod a stops táblát 10 táblára a stop_name szerint egyenletes eloszlásban, alfabetikusan növekvő sorrendben. Amikor név alapján akar keresi, tudni fogod egyből, hogy melyik táblában keress, mert tudod, hogy melyik tábla mettől meddig tartalmaz stop_name elemeket. Ez ugye csak név alapján keresésnél hasznos, úgy ha a felhasználótól elvárod, hogy a begépelt megállónévnek az eleje egyezzen valamelyik megállónévvel.
A stop_times feldarabolása. Mivel ez a tábla rohadt nagy, ezzel is tudsz nyerni időt. Én a stop_id alapán darabolnám fel szintén alfabetikusan hasonlóan ahogy az előbb írtam, el tudod dönteni már a stop_id alapján, hogy melyik táblában keress.
miért stops.stop_name és stop_times.stop_id alapján darabolj, és ne pl stops.stop_lan és stop_times.departure_time alapján? Azért mert az SQLite valószínűleg BTREE indexelést alkalmaz, ami nagyon jó intervallum keresésre. Alkalmazható számon, dátumon, talán még szövegen is! Viszont nem találtam , hogy lenne SQLiteban hash indexelés, ami arra jó, ha szeretnél megtalálni egy elemet konkrét értékkel. Ilyen az, amikor id-k alapján joinolsz. Amikor meg akarod keresni az adott stop_id-n áthaladó járatokat a stop_times táblában adott időponton belül, akkor megkönnyíted az adatbáziskezelő dolgát azzal, ha a particionálással 200e sor helyett csak 20e-ben kell keresnie.
Persze ez csak elmélet. az egész attól is függ, hogy a stop_times táblában először intervallumkeresést hajt végre az időpontra, és utána választja ki stop_id alapján a sorokat, vagy fordítva, de ezt már nem tudom, ki kell próbálni.
Azért jó lehetőség ez az adathalmaz optimalizálásra, mert nincsenek komplikált lekérdezések, csak egy-két féle, így ki lehet alakítani úgy a struktúrát, hogy ezeknek teljesen megfeleljen. Még ami eszembe jutott, hogy az adatbázisok általában elsődleges kulcs szerint teszik sorrendbe az adatokat fizikailag. Szóval ha a stop_times táblában (stop_id, trip_id) -t adsz meg elsődleges kulcsnak ebben a sorrendben, akkor megegyszerűsítheted az adatbáziskezelő dolgát, amikor stop_id alapján keresel, mert az ugyanahhoz a stop_id-hoz tartozó rekordok egymás mögött lesznek elhelyezkede, tehát szekvenciálisan gyorsan ki tudja olvasni az összeset.
De amúgy az is lehet, hogy simán az indexekkel tökéletesen gyorsan fog működni telefonon is, és az egész novella, amit leírtam teljesen fölösleges
-
modder
aktív tag
válasz
pittbaba
#1606
üzenetére
Értem, igazad van. Ezt már nincs kedvem végiggondolni, hogy pontosan hogyan lenne érdemes megcsinálni a kereséseket úgy, hogy a legközelebbi olyan megállót adja meg, ahol adott járat szám megáll, de szerintem adtam ötleteket. A lényeg, hogy mindig jól gondold végig, hogy mi kell, és fölöslegesen ne joinolj táblákat, fölösleges infot ne tegyél bele a selectbe.
Ja, az indexelést se állítsd be minden oszlopra, hátha kell alapon, mert az plusz tárhely, és nem fog mindig gyorsulást okozni a lekérdezésekben.A tábladarabolással kicsit elszaladt velem a ló, csak akkor kezdj bele, ha látod, hogy egyébként lassúak a lekérdezéseid. Szívesen!
-
modder
aktív tag
válasz
pittbaba
#1611
üzenetére
ha csak egy szimpla szelektet csinálsz a stop_times táblában pl az időpontra vagy a stop_id-ra vonatkozóan az is lassú? Miután beállítottad az indexelést, újra betöltötted az adatokat a táblába? Azért járj utána egy kicsit hogyan működik az SQLite, ha nem töltötted be újra az adatokat, lehet nem is építette föl az indexet.
-
modder
aktív tag
válasz
pittbaba
#1615
üzenetére
hát az, hogy a csv-t szépen betöltötted az adatbázisba korábban. Utána ahogy ajánlottuk rátettél a különféle mezőkre indexeket. Ez gyorsított valamit a dolgon? Arra akarok kilyukadni, hogy lehet nem fogja indexelni a már bent lévő adatokat, hanem ki kell ürítened a táblákat és újra betöltened ahhoz, hogy szépen felépítse az indexeket.
De ez csak egy erős tipp, egyáltalán nem értek az SQLitehoz
[ Szerkesztve ]
-
modder
aktív tag
válasz
pittbaba
#1620
üzenetére
miért nem jó az otthoni lomhább szerveren sebességet tesztelni? gondolom nem egy 600Mhz-ces intel pentium III-ad van
A phpmyadminnak van olyan lehetősége, hogy bemásolsz egy fájlt az egyik könyvtárába a szerveren, és onnan veszi fel, így feltöltheted FTP-n a megfelelő könyvtárba, majd importnál kiválasztod a webes felületen. Azért még így is gondot fog okozni a valószínűleg 30 másodperces default php max execution time.
Egyébként nem kell konvertálni csv-ből sql-re, csv-t is tud importálni, és azt lehet, hogy könnyebben szétdarabolod egy egyszerű szkripttel.
Persze ha localhoston tesztelnél, akkor kényed-kedvedre állíthatnál a php exec timeon, és egyszerűbben bemásolhatnád a fájlt a phpmyadmin megfelelő könyvtárába. Felteszel egy Easy PHP-t, abban alapból van phpmyadmin, mysql szerver is, működik out of the box.
Ha tényleg nem egy tízéves az "otthoni lomhább gép", én inkább azon próbálkoznék, nem kell ehhez egy über szerver.
-
modder
aktív tag
Hali,
Most vitatkoztunk egyik ismerősömmel a következőről: Van egy tábla, aminek van egy típus és egy státusz oszlopa, amik eredetileg numerikus típusúak voltak, mondván az nem foglal sok helyet és "gyorsabb". Én pedig mondtam, hogy legyen pl. egy max. 20 hosszú karakter típusú, mert ha nekem az adatbázisban kell kotorásznom, nem fogom fejben visszafejtegetnem, hogy melyik numerikus azonosító mit jelent. A rekordszám nem sok, legyen mondjuk max 10 000, és a rekordok sem nagyon, összesen kb 50 byte pár mezővel.
Én arra gondoltam, hogy tárhelyben alig van különbség a két megoldás között, mivel kevés rekordról van szó. Ha pedig indexeket teszünk a mezőkre, akkor is mindegy, mert nem használunk intervallum keresést, így a hash indexelés a jobb mindkét mezőre, annál pedig megint csak nem számít, hogy egy számot hashelünk vagy egy 20 karaktert.
Ha nem indexelünk, hogy matchelni akarunk az értékekre, akkor sem fog sokat számítani, mert a lemezműveletek jóval többet lassítanak, mint a már egyébként is betöltött rekordokon string matchelés.
Mi a véleményetek?
-
modder
aktív tag
válasz
bambano
#2073
üzenetére
attól, hogy stringként tárolom ugyanazt az információ tartalmú adatot, még nem lesz denormalizált.
A mezők kb max 10-féle értéket vehetnek fel, szóval numerikus számozással 1..10-ig. Csak a kérdés az, hogy mennyivel rosszabb/kevésbé hatékony az, ha én nem numerikus értékként akarom tárolni az információt (és kódban egy enumhoz kötöm), hanem egy max 20 hosszú karakterláncként.
[ Szerkesztve ]
-
modder
aktív tag
válasz
bambano
#2077
üzenetére
Normalizálás kérdés: Lehet, hogy félreértettél. Legyen egy státusz mező és a kérdés, hogy ha van egy aktív és passzív érték, akkor azt numerikusan (0 és 1-gyel) vagy charként ("active" és "passive") érdemes-e tárolni. Ez esetben miért lenne az első normalizált, a második pedig denormalizált abban az értelemben, amit te is említettél, azaz ha normálformákról beszélünk.
Az eredeti kérdésemre pedig kaptam egy linket, ami nagyjából le is fedi az én esetemet: http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
[ Szerkesztve ]
-
modder
aktív tag
válasz
bambano
#2081
üzenetére
Nem nagyon voltak meggyőző érvek a szöveges tárolás ellen. A település név tök jó példa.
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig? Egy településeket tartalmazó táblára mindig szükségünk van, mert valahol el kell tárolni a lehetséges értékeket.
bambano:
Sématervezési szempontból semmivel sem rosszabb, ha szövegként van tárolva a település neve a személy táblában. Ez nem növeli a redundanciát, se nem lesz denormalizált. Redundanciáról akkor beszélhetnénk, ha a lélekszámot is mindig eltárolnánk a település neve mellett a személyek táblában, mert a település neve meghatározná a lélekszámot, így ez utóbbi tárolása is (még mindig a személyek táblában) csak bonyodalmat okozna. Pontosan ez is a redundancia definíciója. Ha már a normálformákat hoztad fel, vegyél elő egy egyetemi jegyzetet, és olvass bele. Vagy pl. ez egész jól leírja: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.2Ha van egy település táblánk, a település neve - mint szöveg - ugyanúgy lehet idegen kulcs a személyek táblában. Nem kell ahhoz numerikus elsődleges kulcs, hogy kikényszerítsük a személyek táblában, hogy csak bizonyos település neveket lehessen felvinni.
"azok után pedig, hogy azt állítottam, az sql-ben a teljesítményt feláldozzuk más célok elérése érdekében, ez a link mennyiben releváns?"
Attól, hogy állítasz valamit, az még nem biztos, hogy igaz. Ez úgy hangzott, mintha az SQL használatával nagyságrendekkel rosszabb teljesítményt érnénk el, pedig az SQL csak arra jó, hogy nem neked kell megírnod, hogy mikor melyik indexeket akarod használni. De az SQL végrehajtási tervbe fordítása mellett még száz másik szempont van, ami nagyban befolyásolja a lekérdezés sebességét, aminek semmi köze ahhoz, hogy milyen lekérdezőnyelvet használsz. És persze az sql-t is többféleképpen írhatod meg, hogy segíts az optimalizálónak a hatékonyabb végrehajtási terv elkészítésében.martonx: Köszönjük a hozzáértő, szakmailag megalapozott hozzászólást
Ami megfontolandó:
- karakterkódolási problémák: Ez általában olyan, hogy vagy fennáll az egész adatbázisra és az őt használó alkalmazásra, vagy nem, ami persze más szöveges mezőket is érint.
- "könnyebb elírni": miért, a numerikus azonosítót nem könnyű elírni?
- index sebessége: annyival lassabb egy pl. 30 karakter hosszú CHAR vagy VARCHAR mezőn az index használata?
- tárolás: a szöveg több byte-ot használ felA hatékonysági kérdésekkel csak akkor érdemes ilyen mélyen foglalkozni, amikor a tárolási kapacitás és pl. a beszúrási (index frissítési) sebesség sarkalatos pont, ami egy "egyszerű" webalkalmazásnál ritkán fordul elő.
pazsitZ: leginkább mysql cli, phpmyadmin vagy egyéb kliens programra gondoltam, amikor kotorászásról beszéltem.
[ Szerkesztve ]
-
modder
aktív tag
Hát igen, végülis a kérdés az volt, hogy mi a véleményetek. Nem is akarok meggyőzni senkit, de szerintem nem árt, ha néha megkérdőjelezünk valamit, mert aztán lehet, hogy kiderül hogy egy egyszerű berögződés. Az előző posztomban igazából csak levontam magamnak a következtetést (meg válaszoltam egy-két hsz-ra).
-
modder
aktív tag
válasz
PazsitZ
#2092
üzenetére
Csak hogy ne kanyarodjunk el nagyon, az előfeltételek, amiket már legelőször is említettem (vagy nem) a kutyafuttában összedobott hozzászólásomban:
- Átlagos/kis terhelésű weboldalról van szó, nem valami hatalmas terhelésről. Mit tudom én, napi pár 10e oldal lekérés
- Kis adatbázisméret: pár 10e rekord, pár 10MB adatbázis méret (ez mondjuk egy blog mérete sok cikkel)Azért fontos ezt megemlíteni, mert nagy tábláknál, amik sok I/O műveletet igényelnek, fontos, hogy ne növekedjen duplájára a rekord méret egy CHAR field miatt.
Mondok két előnyt:
- az egyik, amiből az egész kiindult, hogy ha a lekérdezéseket szerkesztem valamilyen kliens programban, akkor jobban esik az agyamnak, ha a konkrét információt látom a mezőben, ha ellenőrzöm, jó lekérdezést írtam-e meg. Ide tartozik még, ha valaki (vagy én) évek múlva hozzá akar nyúlni a szoftverhez és adatbázishoz, leegyszerűsödik a dolga.
- a városos példánál maradva nincsen szükség joinra, ami egy kicsit le tudja egyszerűsíteni a lekérdezést, ha egyébként az nagyon összetett; sok másik jointot is tartalmaz.
- ha szoftverben valamilyen ORM frameworkot használunk, közvetlenül benne lehet a város neve a személyek entitásban, ahelyett, hogy egy varos entitason keresztül kéne hozzáférnem az értékhez. (Elképzelhető, hogy egy-egy kapcsolatnál be lehet süllyeszteni a személy entitásba a várost, de most nem jut eszembe, hogy pl. JPA-nál lehet-e)...három lett
Egyébként én először olyan információt akartam szövegként tárolni, ami tipikusan egy enum (SQL) típus lenne, és a mező "kardinalitása" olyan 10 db érték körül mozog. Enummal az a baj, hogy nem elég dinamikus, ha új értékre van szükségem az alkalmazásban, akkor módosítanom kell az elérhető enumok listáját, ami MySQLnél azt is eredményezheti, hogy újragenerálja az egész táblát. És az enumra lett volna alternatíva a numerikus vagy szöveges érték, ahol én arra szavaznék, hogy legyen csak szöveges pl.
Státusz = {"active", "inactive", "suspended", "deleted"} ahelyett, hogy 1,2,3,4-t tennénk a mezőbe. És szerintem ez tényleg nem nagy eretnekség.VÁLASZOK:
----------------------------------------------------bambano, pazsitZ: De fontos ha rossz teljesítményt produkálna a szöveges tárolás. Az volt a gondom, hogy azt sugalltad, az SQLlel egyébként is teljesítményt vesztünk, következésképpen mindegy, hogy a szöveges tárolással teljesítményt vesztünk. Ezzel ki is dobhatnám az érvem, miszerint nem volt teljesítménybeli különbség. Egyébként itt az említett link - aki lemaradt volna -, érdemes megnézni, hogy 1.5 millió rekordnál, kis rekord méretnél, tehát befér a memóriába a tábla, nem volt különbség. http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
Egyébként nem hálós adatbázisról beszélünk, hanem relációs adatbázisokról (és nem SQL adatbázis).martonx: Ebben teljesen igazad van, hogy szöveges mező index esetén, ha mysql B-TREE indexről van szó, az index mérete bizony jócskán megnövekedhet a numerikus indexhez képest, de a keresés nem lesz annyival lassabb, mert a string összehasonlítás csak az első nem egyező karakterig hasonlít, a fa magassága pedig nem nő akkorát, jellegéből adódóan. Hash indexnél pedig mindegy, mert ott úgyis csak a hash van eltárolva az indexben.
pazsitZ: Szóval mégis csak szükséged van egy másik táblára.
Ahol mondjuk település adatokat tárolsz. Ekkor viszont már minek a string?
(Arról az esetről van szó, ha szövegként tárolom a város nevét, de kell egy másik tábla, ahol az összes lehetséges város tárolva van) Nincs szükségem string joinra lekérdezésnél, hiszen a város neve ott van a személyek táblában. Beszúrásnál van szükség idegen kulcs ellenőrzésre, ami index alapján történik.martonx: Ráadásul pont ez az az általad is sokat kritizált gányolós, kókányolós, hozzáállás az, ami miatt aztán tömegek bele is kövesednek ebbe a programozói attitűdbe. Elvégre minek normálisra megcsinálni az indexeket, meg a relációs kapcsolatokat, há' nem sokkal egyszerűbb, mindent beb***ni egy táblába, megfelelő indexeket rátenni, és ha megnézem ezer sorig még gyors is?
Azért ez nem teljesen így van. Akkor lenne kókányolás (amúgy imádom ezt a szót, én is sokat használom), ha ezzel alapjaiban véve mennénk szembe a relációs adatbázis elvekkel, de ahogy kifejtettem a normalizálós hozzászólásomban, erről szó sincs. Egyébként én is nagy teljesítményhajhász vagyok, de nem szeretek lemondani a kényelemről ott, ahol nem kapok érte cserébe elég nagy előnyt teljesítményben. És úgy érzem, amíg tudom, hogy nem lesz több száz megabyteos az adatbázisom, addig ez egy ilyen helyzet. -
modder
aktív tag
jaja, önigazolást
Amúgy kb. mindenki azt írta, hogy "persze, nem eretnekség, csak nem úgy szoktuk". Formálisan helyes, teljesítményben alig van/nincs különbség. Akkor pedig nem kókányolás, akármennyire is ezt akarjátok sulykolni. (persze nem mindenki)Nekem is van annyi tapasztalat a hátam mögött, hogy magabiztosan megkérdőjelezzek egy ilyen "best practice"-t, főleg ha találkoztam velük nyílt forráskódú keretrendszerekben, ahol előszeretettel tettek enum típusú értéket szöveg mezőbe, és még senki nem panaszkodott, hogy szar lenne a rendszer. Viszont fejlesztésnél rohadt jól jön, amikor nem egy nyamvadt számot látok a mezőben, amikor azt ellenőrzőm, hogy jó értéket tett-e az adatbázisba. Vagy azt, hogy jól működik-e az ORM cache, és tényleges adatbázis értéket olvasok, nem egy cache-elt halmazt. - Tegyük hozzá, nem egy egyszerű CRUD alkalmazásról van szó
De ne értsetek félre, nem mondom, hogy az egyik vagy a másik megoldás helyesebb, mindig sok mindentől függ, de amit felvetettem, semmiképpen sem helytelen. Szóval nem akarom megreformálni a nézeteket
Csak az idők során kezdek rájönni, hogy érdemesebb a legpraktikusabb megoldások felé menni, ha azok nem sértenek durván alapelveket, mert a szoftverfejlesztésben mindig előbukkanhat egy szopatás, és akkor én minél kevesebbet akarok oblákolni - és szoptam én már túltervezett adatbázistól is, ami nagyon megállta a helyét tankönyv szerint, de 1 nap volt, mire kitaláltam azt a furfangos lekérdezést, amivel azt kaptam meg, amit szerettem volna.
