abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 5
včera 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 6
včera 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 1
včera 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
včera 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
včera 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
1.12. 15:16 | Komunita

Na GOG.com začal zimní výprodej. Řada zlevněných her běží oficiálně také na Linuxu. Hru Neverwinter Nights Diamond lze dva dny získat zdarma. Hra dle stránek GOG.com na Linuxu neběží. Pomocí návodu ji lze ale rozběhnout také na Linuxu [Gaming On Linux].

Ladislav Hagara | Komentářů: 1
1.12. 13:14 | Bezpečnostní upozornění

Byla vydána verze 2.7.1 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Řešeno je několik bezpečnostních problémů. Aktualizován byl především Tor Browser na verzi 6.0.7. Tor Browser je postaven na Firefoxu ESR (Extended Support Release) a právě ve Firefoxu byla nalezena a opravena vážná bezpečnostní chyba MFSA 2016-92 (CVE-2016-9079, Firefox SVG Animation

… více »
Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 761 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Návrh databáze - xml nebo ohýbání struktury?

28.5.2011 02:23 dbm
Návrh databáze - xml nebo ohýbání struktury?
Přečteno: 929×
Ahoj. Mám databázi kterou využívám pro "kešování" dat. Mám centrální tabulku s uživateli. Dále aplikaci, která pravidelně čte předhozené textové soubory (různé systémy uživatelských účtů) a podle potřeby vytvoří tabulku s potřebnými datovými typy a importuje do ní data. Pak mám další tabulku, ve které mám seznam všech takto vytvořených tabulek. Je to takový jednoduchý systém který má za úkol jediné - rychle najít uživatele.
centrální tabulka:

uzivatel | kategorie
--------------------
jarda    | kat.
...


tabulka názvů tabulek:

tabulka_nazev
-------------
soubor1
...


příklad vstupního souboru:

uzivatel(string), kvota_limit(int32), certifikat(bin)
jarda2, 100, BINARNI_DATA

takový soubor se převede do tabulky "nazev_souboru":
uzivatel | kvota_limit | certifikat
-----------------------------------
jarda2   | 100         | BINARNI_DATA

s tím, že se konvertují datové typy (string na varchar, int32 na int, bin na blob)



Při výpisu uživatelů pak není problém zobrazit všechny lidi, který mají kvota_limit XY  a jsou v kategorii KATEGORIE. Vlastně je to velice rychlé, protože se provede jednoduchá podmínka where na left joinech tabulek.
Teď co mám za problém. Ačkoliv je tento návrh rychlý a efektivní, tak se mi vůbec nelíbí zasahovat dynamicky(i když jen občas cca 1x ročně) do struktury db. Proto hledám jiný způsob ukládání dat. Napadlo mě přidat centrální tabulce sloupec a všechno mít v XML struktuře. Jak je na tom třeba mysql či postgresql s hledáním v takové struktuře? Nebo neměli byste lepší nápad na návrh databáze?

Odpovědi

28.5.2011 08:31 Kit
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
To vypadá, jako bys hledal fulltext. Také záleží na tom, kolik řádek máš v databázi. Jestli je to jen pár tisíc, tak databázi nezatíží ani sekvenční hledání s LIKE. Ovšem hledání jména uživatele v XML bude asi náročnější, než třeba v CSV. XML však můžeš s úspěchem využít k ukládání neklíčových položek.
28.5.2011 11:37 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Myslel jsem to takhle:
uzivatel | kategorie | atributy
------------------------------------
jarda    | kat.      | XML_STRUKTURA
Těch řádek je tam teď cca 500 000 v každé spojované tabulce a přibývají další (jsou to takové speciální fiktivní uživatelské účty). V současnosti jsem schopen po spojení 5 takových tabulek vyhledat data (samozřejmě indexovaná) do cca 2 sekund. S manuálním vyhledáváním (pomocí aplikace) v XML by to trvalo déle, proto mě zajímá něco co přímo podporuje databáze, ideální by bylo kdyby zvládla hledat v XML, což ale asi nepůjde? Jakou jinou strukturu bych mohl použít pro ukládání dat, aby hledání bylo stejně rychlé jako doposud?
28.5.2011 12:54 Kit
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Zásadní otázka: Podle čeho hledáš? Pokud podle libovolného slova, tak ti pomůže jen fulltext.

Mám podobnou databázi v obyčejném textovém souboru a prohledávám ji sekvenčně pomocí regulárního výrazu. Skvělá rychlost, maximální spokojenost. Pokud budeš jakkoli sekvenčně prohledávat databázi, degraduješ ji do pozice pomalejšího textového souboru. To už je lepší všechny možné klíče naházet do key->value store.

Klidně používej XML, ale klíče je vhodné uložit tak, aby se daly indexovat. Hledání klíčů v XML není dobrý nápad.

Jaké máš dotazy do své databáze? Možná je řešení jednoduché až primitivní. Jen je potřeba vědět, co vlastně hledáš, které položky jsou klíčové.
28.5.2011 15:42 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Vyhledávám podle všech položek (klidně najednou). Tudíž všechny sloupce jsou vlastně klíčové (i v reálu je to všechno přeindexované). Dotazy jsou typu select a jde o to většinou najít všechny uživatele, kteří jsou v nějaké kategorii, jejich jméno začíná nějakým písmenem a jejichž atribut soubor1.atribut1 je menší než 50 a jejichž soubor2.atributX se rovná "řetězec". Na takové věci by mi fulltext asi nepomohl. Tímto způsobem mohu i řadit podle různých datových typů (datetime, int, varchar ...). Na tom mém návrhu mi vadí ještě to, že jsou některé záznamy redundantní - z důvodu rychlosti při spojování je lepší spojit 5 tabulek s redundancí než 50 tabulek v 3NF bez redundance.
28.5.2011 14:44 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
A jaké jsou XML data, která se tam ukládají? Je to XML víceúrovňové, nebo ploché (každý uživatel má X vlastností)? A podle čeho se vyhledává?

Nestačilo by navrhnout pevné tabulky pro data, podle kterých se vyhledává a kromě toho jednu tabulku s údaji uživatel - název vlastnosti - hodnota vlastnosti?
28.5.2011 15:49 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Zatím žádná, ale pokud bych použil XML, tak asi použiji přímo XSD. Stromově by struktura vypadala následovně:
         soubor1
            |
   ------------------------
   |                      |
atribut1               atributN
   |                   |       |
hodnota1           hodnota1 hodnota2
Takže by to bylo víceúrovňové, uživatel má vždy N vlastností (atributů) a každá vlastnost může mít několik hodnot.
28.5.2011 15:52 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Já bych se na to vykašlal, namísto XML bych generoval JSON a ten bych indexoval v Elasticu. Vyhledávání jedna báseň.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
28.5.2011 17:04 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Umí to i wildcard znaky? A jak to vlastně funguje? Z jejich popisu mi to není moc jasné - jasně je to search engine, ale nad čím to vyhledává - co to používá jako default storage (persistentní/nepersistentí ...)?
28.5.2011 17:30 Kit
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Připadá mi to jako variace na CouchDB.

Při shlédnutí vyhledávacích požadavků mě napadlo jednoduché řešení: Textový soubor, každý záznam jeden řádek, struktura řádku JSON. Žádné indexy, vyhledávání grepem. Možná to bude i rychlejší.

Klidně by to mohlo být i v několika souborech, každý s jinou strukturou.
28.5.2011 18:43 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
No relační databáze mi umožňuje použít transakce. Během aktualizace záznamů může bez problému probíhat několik selectů. Při selhání aktualizace se jen zruší transakce a data jsou v pořádku. Toho s textovým souborem nedosáhnu (ani s couchdb myslím ne - tam i přes verzování není zaručena "správnost dat").
28.5.2011 21:39 Kit
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Netušil jsem, do jaké míry vyžaduješ ACID. Také jsi to nikde nepsal a požadavky na hledání spíš svědčily o opaku. Podle popisu hledání mám spíš pocit, že ve tvém případě indexy místo pomáhání spíš škodí. Proto jsem navrhl jejich odstranění, případně redukci.

Při zvyšování výkonnostních nároků na databázi se často sáhne po NoSQL řešení, do kterého patří i XML a JSON. Ovšem nesmí se zapomínat na indexy, protože prohledávání neindexovaných objektů je drahé.

Také bys mohl mít jednotlivé tabulky jako JSON objekty. Aktualizoval bys pak celou tabulku naráz. Pokud vyhledáváš výrazně častěji než aktualizuješ, mohlo by to být řešení. Prohledání 50 objektů regulárním výrazem je rychlejší, než prohledávání 500000 malých neindexovaných objektů. Zejména pokud víš, ve kterém z těch 50 objektů se požadovaná data nachází.
29.5.2011 03:24 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
No jediná NoSQL databáze která by se mi líbila je MongoDB, ale na ní jsem se dočetl o možnosti ztráty dat a o memory leaks, protože je to relativně mladá db, tak nevím.
29.5.2011 08:26 Kit
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
NoSQL je víc druhů, MongoDB se hodí tam, kde potřebuji škálovat. A když už budu potřebovat škálovat, podívám se nejprve, jak to dělá Cassandra.

Na popsaný problém by se dala klidně použít třeba i DB4, ale nesměl bys být líný si v ní vytvořit všechny potřebné indexy ve vlastní režii.
29.5.2011 10:56 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
No upřímně řečeno jak procházím různé nosql db, říkám si, že by bylo moudřejší zůstat u SQL databáze a vyřešit to nějak tam.
9.6.2011 16:17 univerz
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
od cca 1.8 je single server durability defaultne nastavenie. zatial mi bezi cca 2 mesiace v pohode bez vyrazneho zrania pamate.
29.5.2011 10:25 Ondra
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Napadá mě DB2 v9.7, kde je technologie PureXML, která umožňuje uchovávat nativně XML dokument v databázi, takže je to přesně to co chceš:
uzivatel | kategorie | atributy
------------------------------------
jarda    | kat.      | XML_STRUKTURA
Dá se s tím pracovat jak pomocí SQL, tak pomocí XQuery pro XML strukturu. IBM DB2 v9.7 Express-C je na stránkách IBM volně stažitelná a použitelná i pro komerční účely. Jediné omezení jsou tam 2 CPU a 2 GB RAM. Velikost databáze omezená není.

Pokud ale vyžaduješ MySQL nebo Postgres, tak: http://wiki.postgresql.org/wiki/XML_Support - taky koukám, že umí XQuery http://dev.mysql.com/tech-resources/articles/xml-in-mysql5.1-6.0.html - tam je to o něco horší
29.5.2011 12:44 dad
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
k te DB2.

Jak se projevuje to omezeni? Jestlize mam stroj s vice nez 2 GB RAM, vubec se ta db nenainstaluje, nebo nenastartuje, nebo co se stane?

2 CPU jsou jadra nebo 2 sockety?
29.5.2011 14:33 kovariadam | skóre: 12 | blog: biased | Košice/Brno
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
normalne to pojde, len viac nevyuzije
30.5.2011 01:31 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
No, zkušenosti nemám, ale zdravej rozum mi říká, že XQuery nikdy nedosáhne rychlosti vyhledávání v db tabulkách. Jestli jsem to pochopil, tak struktura xml je víceméně vždy stejná. Pak to jde dát do vhodných tabulek. Např.



Skupina 1:N   Uživatel    1:N Hodnota atributu (Int)      N:1 Název atributu
                          1:N Hodnota atributu (Varchar)  N:1
                          1:N Hodnota atributu (Datetime) N:1
                              ....
Vyhlednávání rychlé, indexované, struktura univerzální, ACID. Je něco, co to neumí?

PS: Pokud se něco dělá podle prvního písmene skupiny, je název skupiny zřejmě složený datový typ, takže bych ho rozdělil.
30.5.2011 02:09 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Je něco, co to neumí?
Třeba řazení např. pokud budu chtít řadit podle atributu1 vzestupně a zároveň podle atributu2 sestupně (SQL = order by atribut1, atribut2 desc). Také to neumí datové typy (leda že bych měl tolik sloupců kolik existuje datových typů a hodnotu sypal do toho správného).
30.5.2011 11:37 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Neumí ?

SELECT * uzivatel  u 
INNER JOIN atribut a1 ON (u.id = a1.uzivatel_id AND a1.nazev_id = :nazev1)
INNER JOIN atribut a2 ON (u.id = a2.uzivatel_id AND a2.nazev_id = :nazev1)
ORDER BY a1.hodnota, a2.hodnota desc
Jo, nenadefinuješ složený index, ale jednoduchej index atribut(nazev_id, hodnota) to použije, tak pokud není první řazení podle nějakýho hodně neselektivního kritéria, tak to je dostatečný.

Na ty nejpoužívanější pak můžeš použít materializovanej view, popř. si nejpoužívanější vlastnosti sypat rovnou k uživateli. Furt je to rychlejší než cokoli, co dostaneš přes XPath nebo XQuery.

Různý typy můžeš řešit více tabulkama či více sloupci, těch typů zas tolik není (int, float, datum, string).
30.5.2011 13:01 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Vyzkouším to, ale nejsem si jistý jestli to má šanci fungovat (kvůli náročnosti). Takhle vlastně místo toho, abych měl 5 tabulek po 500 000 řádcích a třeba 10 sloupcích budu mít 1 tabulku s [5 * 500 000 * 10] řádky, nad kterou budu provádět joiny nad sebou samé.
30.5.2011 13:37 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
No můžeš nechat současnou tabulku a do tědlech "metatabulek dávat jen ty" přidávaný data.
30.5.2011 14:53 Ondra
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Ano i tak by se dalo, pokud se chceme držet ploché struktury. Otázka je, jak má postavenou aplikaci, která s těma datama pracuje. To by měl při tom návrhu zohlednit, pokud nedělá všechno na zelené louce.

BTW. PureXML je dost rychlé. Nebál bych se toho.;-) http://www-01.ibm.com/software/data/db2/xml/performance.html
30.5.2011 15:18 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Já věřím, že je dosti rychlé. Furt ale musí zvládat obecnější množinu dat, takže nemůže bejt tak optimalizovanej jako dotaz nad relační algebrou. Fór je v tom, že tadle aplikace defakto nepotřebuje nijak velkou varibailitu: akorát občas má tu a tam ten a ten objekt o vlastnost víc či míň. Síla xml se projeví v případě, kdy o datech moc nevíme a tak nemůžeme připravit nějakej obecnej mustr. To ale myslím není tento případ...
30.5.2011 17:24 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Ještě k tomu sql dotazu na řazení. Musel jsem sice použít left joiny (protože nechci ztratit řádky uživatelů jen proto, že nemají ty a ty atributy), ale nevypadá to vůbec špatně. Rychlostně je to +- nastejno s mým stávájícím řešením, až jsem se divil. Ještě je ale potřeba vyřešit ty problémy s datovými typy. Když mám tabulku se sloupci hodnotaINT, hodnotaDATE, hodnotaVARCHAR atd., tak se použije vždy jen jeden, ostatní budou NULL. Jak vyberu ale ten správný sloupec? Nechce se mi to řešit aplikačně, lze toto řešit i na databázové úrovni (tak, že pro každý nalezený řádek vypíše z hodnota1-hodnotaN vždy tu, která není NULL)?
rADOn avatar 30.5.2011 18:40 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Nechce se mi to řešit aplikačně, lze toto řešit i na databázové úrovni (tak, že pro každý nalezený řádek vypíše z hodnota1-hodnotaN vždy tu, která není NULL)?
Hledáš sql funkci COAELSCE
"2^24 comments ought to be enough for anyone" -- CmdrTaco
rADOn avatar 30.5.2011 18:42 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Ups, chtel jsem říci COALESCE
"2^24 comments ought to be enough for anyone" -- CmdrTaco
31.5.2011 10:11 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?

COALESCE by IMHO bylo zbytečně pomalý - navíc: jak poznáš, podle kterýho typu řadit jako první?

Osobně myslím, že budeš muset někde určit, jakej typ mají daný data. Spoléhat na autodetekci se mi nezdá úplně dobrej nápad. V tu chvíli je podle mě nejlepší nespoléhat na automatiku, ale prostě si udělat konfigurák, kam předepíšeš tendle sloupec je INTEGER, tendle je DATETIME atd.... Sloupce, který v konfiguráku nebudou se pak budou porovnávat jako řetězce.

Výhoda toho je, že pokud budeš potřebovat nějaký spešl řazení, který DB nativně nenabízí, tak se to velmi snadno doimplementuje apod. Jako bonus tam i můžeš snadno implementovat sloupce, který budou přímo v tabulce uživatele a podobný vychytávky. Další výhoda bude jednoduchá "změna typu" danýho sloupce atd...

rADOn avatar 31.5.2011 12:44 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
COALESCE by IMHO bylo zbytečně pomalý
Pomalejší než index? Určitě. Pomalejší než nějaká hrůza zahrnující xml a fultext? Nevím nevím.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
31.5.2011 14:39 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
To asi jo, no ona jde naindexovat i expression, o to nejde. Takže zas o tolik pomalejší by to ani nebylo (akorát by byly větší indexy). Ale stejně z principu nejde určit, pro jakou vlastnost se má použít jakej sloupec, takže to musí určit programátor (přinejmenším pro zápis). A když to určuje pro zápis, tak proč by to neurčil i pro čtení?
rADOn avatar 31.5.2011 14:54 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
A když to určuje pro zápis, tak proč by to neurčil i pro čtení?
To já nevím, já jen odpověděl na dotaz jak najít nenullový sloupec. Ale v původním dotazu nešlo o to jak překopávání schématu přizpůsobit aplikaci, ale jak se strojovému překopávání tabulek vyhnout úplně. Udělat ze sloupců vazbu řádky je IMO celkem dobrý způsob jak to udělat, rozhodně lepší než nějaká hrůznost s xml a fulltextem.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
31.5.2011 09:30 dush
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?

Nastuduj si EAV model, mohlo by to byt to co hledas http://en.wikipedia.org/wiki/Entity-attribute-value_model

Pripadne pokud chces pouzit MySQL + XML http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html

9.6.2011 09:59 dbm
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
Tak jsem si chvilku hrál s EAV modelem a přijde mi to nějaké pomalé. Mám tabulky users, attributes a eav_"datovy_typ". Jak z toho co nejefektivněji dostanu data? Dotaz
select users.uid, users.name, eav_blob.value, eav_date.value, eav_datetime.value, eav_float.value, eav_int.value, eav_string.value, eav_time.value from users left join eav_blob on (users.uid = eav_blob.uid) left join eav_date on (users.uid = eav_date.uid) left join eav_datetime on (users.uid = eav_datetime.uid) left join eav_float on (users.uid = eav_float.uid) left join eav_int on (users.uid = eav_int.uid) left join eav_string on (users.uid = eav_string.uid) left join eav_time on (users.uid = eav_time.uid) inner join attributes on (attributes.aid = eav_blob.aid OR attributes.aid = eav_date.aid OR attributes.aid = eav_datetime.aid OR attributes.aid = eav_float.aid OR attributes.aid = eav_int.aid OR attributes.aid = eav_string.aid OR attributes.aid = eav_time.aid)
zabere celou sekundu a to tam nemám skoro žádná data a zatím jsem ani nepoužíval eav entity.
9.6.2011 12:54 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Návrh databáze - xml nebo ohýbání struktury?
No protože ty joinuješ přes všechny atributový tabulky najednou - tzn. ve výsledku budou všechny možný kombinace atributů: intvalue, stringvalue, datevalue, datetime

Navíc tam duplikuješ users.name v každym dotazu, to taky není moc dobře, lepší je udělat pro každý "set" zvlášť (první dotaz select name, id from users, druhý pro atributy a na aplikační úrovni spojit přes id).

Jestli to chceš dělat takhle, musíš udělat ještě jednu mezitabulku eav_id, která bude přidělovat idčka sdílená pro všechny tabulky a joinovat

eav_id INNER JOIN atributy ON (eav_id.atrributes_id = atrributes.id) LEFT eav_date USING (id) LEFT eav_string USING (id) ....

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.