ugrás a tartalomhoz

Deconstructing Databases

Hojtsy Gábor · 2006. Szep. 23. (Szo), 17.28
Struktúra helyett full-text search?
 
1

a paci, az oldalai meg az esés

zsepi · 2006. Szep. 25. (H), 10.28
Lehet, hogy bizonyos problémákra jó ez a megoldás, de nem hiszem, hogy mindenre alkalmas lenne. Alant néhány meglátás:
  1. Alap dolog, hogy egy adatbázist nem csak egy alkalmazás használ. Lehet, hogy a mi kis alkalmazásunk remekül boldogul egy id, longtext oszlopokkal rendelkező táblával, de nem hiszem, hogy adatbányászathoz, riportáláshoz, stb. ez használható lenne. Márpedig e két tevékenység elég gyakori az üzleti életben.

  2. A "túlszervezettség"-nek vannak előnyei. Nem véletlen, hogy relációs adatbázisokról beszélünk. Nem csak egy halom adat van, hanem jelentéssel bíró, egymással összefüggő adatok. Az adatbázis "túlszervezett" szabályai biztosítják, hogy konzisztensek legyenek.

  3. A felhasználóbarátság nem abból áll, hogy egy inputot (v.ö.: ellenőrző füzet vagy egy sima írólap) adunk a felhasználónak, mert némileg áttekinthetetlen lesz az eredmény (ld. mikor ezt írom, már nem látom, mi van a hozzászólásom elején). Ehhez egy UI tervező biztos jobban ért. Nem kell egy az egyben az adatbázis szerkezetének megfelelő űrlapot kirakni a felhasználónak, de fontos, hogy valami módon szervezett legyen. Az, hogy ezt hogyan tárolja majd le a program, az egy más kérdés.

  4. Arra persze lehetőséget kell adni, hogy a felhasználó tetszőleges struktúrájú adatot is rögzíthessen a rendszerben, mert simán előállhat az a szituáció, hogy olyan adatokat is rögzíteni kellene egy alkalmazásban, amit korábban nem. Az időszak alatt, amíg a program nem képes struturáltan rögzíteni ezeket az adatokat, valahol muszáj vezetni ezt is. Két lehetőség:
    • egy text mezőbe (egyéb info) a megfelelő adatbázis rekordhoz hozzárendeli a felhasználó, egy sztenderd formátumban. Ez esetben program módosítása után egy egylépcsős adatmigráció történik, s máris szép és jó minden.

    • a program csak azt képes rögzíteni, amire eredendően készítették. Ekkor a felhasználók nekiállnak excelbe (természetesen több, egymással nem kompatibilis excelbe) rögzíteni az információkat, ahol úgysem lesz meg a megfelelő primary key, hanem valami természetes azonosító, amit elírnak úgyis, stb, stb. Ezt migrálni - rémálom.


Rugalmasnak kell lenni, de nem szabad átesni a paci másik oldalára. A megfelelő eszközt a megfelelő feladatra. Biztos vagyok abban, hogy Google-ék alaposan átgondolták, miért ezt használják, de a kedves blogíró javaslata, miszerint
Greg makes a terrific point that could be applied more broadly to business applications, and might even be a design approach for Web 2.0 applications.

kicsit hype jelleget ölt, s kevéssé tűnik átgondoltnak. Ez olyan, mint a nemrég beköldött kis képregény-blogmarkom.
2

4. pont

Anonymous · 2006. Szep. 26. (K), 08.45
Erre az a megoldás, hogy egy olyan termékre, amelybe változó adatok kerülnek be, support szerződést kell kötni ls akkor az MVC megfelelő részeinek izélgatásával majd lehet új adatokat is rögzíteni. Persze, tudom, a kis pénztárcájú ügyfél nem szeretne még fizetni, hanem ő mindent akar tudni csinálni. És itt a mérnöki munka nehézsége. :)