Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Tuxik 05. 07. 2015, 07:46:15
-
Ahoj, potreboval bych vztvorit SQL dotaz (jedna se FireBird, ale muze byt i pro MySQL, kdyztak prevedu, kdzby to neslo jinak).
Mam tabulku, ve ktere jsou k urcitemu ID pritrazeny vlastnosti. Vzdy jedno ID, jedna vlastnost na radku. ID se muze opakovat a muze mit i vic vlastnosti. Potrebuji vybrat pouze ID, ktere ma vic konkretnich vlastnosti. Pokusim se vysvetlit tabulkou.
+---+----------+
| ID | Vlastnost |
+---+----------+
| 1 | A |
| 2 | A |
| 2 | B |
| 3 | A |
| 3 | C |
+---+----------+
Potrebuji vybrat jen ID, ktere ma prirazenu napr. vlastnost A i B (v tomto pripade ID 2), pripadne rozsirit na noznost vybrat kazde ID, ktere ma A a k tomu B nebo C (v tomto pripade ID 2 a 3).
Existuje nejaka jednoducha moznost, nebo to budu muset postupne prochazet? Bylo by to idealni v ramci jednoho dotazu, aby podminku mohl zadat uzivatel, klidne v nejakem zapisu neco jako "SELECT DISTINCT ID from TBL WHERE Vlastnost=A and (Vlastnost=B OR Vlastnost=C)", respektive jenom podminkove casti zapisu, ale aby to slo idealne jednim dotazem a nemuselo se resit nejake slozite parsovani dotazu a jeho provadeni.
Dekuji za rady
-
GROUP BY ID, Vlastnost HAVING COUNT(Vlastnost)>=2 by nešlo?
-
ten tvoj:
SELECT DISTINCT ID from TBL WHERE Vlastnost=A and (Vlastnost=B OR Vlastnost=C)
je na tento ucel presne to co hladas.
-
ten tvoj:
SELECT DISTINCT ID from TBL WHERE Vlastnost=A and (Vlastnost=B OR Vlastnost=C)
je na tento ucel presne to co hladas.
Co když je vlastností víc než 3? Třeba 10?
-
SELECT id FROM table GROUP BY id HAVING COUNT(vlastnost) >= 2;
-
SELECT id FROM table GROUP BY id HAVING COUNT(vlastnost) >= 2;
tak ich doplnis do podmienky?
-
Upozornuju, nasledujici reseni je pro FireBird (zkouseno na verzi 2.5)!!! Pro MySLQ je to podobny, ale misto LIST se pouziva GROUP_CONCAT a mozna jeste nejake drobne odlisnosti.
Uz jsem to vyresil, vytvoril jsem si vlastni pohled
create view MujPohled (ID, Vlastnosti) as select distinct ID, LIST('*' || Vlastnost || '*','') from Tabulka group by ID;
coz mi vytvori radky v MujPohled neco jako
ID Vlastnosti
1 *A*
2 *A**B*
3 *A**C*
takze kazdou vlastnost mam ohranicenou z obou stran * a vyhledavam v nich pomoci napr
select ID from MujPohled where Vlastnosti like '*A*' and Vlastnosti like '*B*';coz mi najde vsechny ID obsahujici A i B a logika WHERE se da kombinovat neomezene, coz se mi hodi, protoze hledani generuju z PHP pomoci pravidel vytvorenych uzivatelem pres par tlacitek - '(' ')' 'AND' 'OR' 'pridat vlastnost'.
Sice se mi to zda porad nejaky prekombinovany a mozna bude existovat jednodussi metoda, ale takhle je to na tech par tisic radku co resim i docela rychly a hlavne to skladani podminek funguje bezvadne.
-
Sice se mi to zda porad nejaky prekombinovany a mozna bude existovat jednodussi metoda, ale takhle je to na tech par tisic radku co resim i docela rychly a hlavne to skladani podminek funguje bezvadne.
Ono nejde o to, ze to je překombinované, ale na větších datech to by to bylo asi i dost pomalé - je tam jednak skládání stringu, a potom vícenásobný LIKE. Pro pár tisíc řádek to nepoznáte, ale pro víc než desítky tisíc to může být dost špatné - nicméně dobré řešení asi neexistuje - způsob jaký používáte se označuje jako EAV a je to známý antipattern - taky proto se Vám s tím špatně dělá.
Obvyklé řešení je založené na vícenásobném selfjoinu, které by mělo být docela rychlé pokud podmínkám bude odpovídat tak do 3% řádků. Potom už asi může být rychlejší scan s HAVING.
-
Obvyklé řešení je založené na vícenásobném selfjoinu, které by mělo být docela rychlé pokud podmínkám bude odpovídat tak do 3% řádků. Potom už asi může být rychlejší scan s HAVING.
Jedná se o synchronizaci dat mezi databází dodavatele a e-shopem, která probíhá max 1x denně a jedná se o pár tisíc položek (z nichž se dál zpracovává jen pár set) Trvá to v řádu vteřin a nějaký výrazný skokový nárust objemu dat se nedá očekávat, takže zatím je to v pohodě.
Ale děkuji, aspoň jsem o něco chytřejší. Většinou pracuju s SQL jen v rámci vlastních projektů a datový modely si vytvářím tak, aby to bylo co nejpohodlnější a nejrychlejší na používání. Zpracování cizích databází (a ještě doprasených, většina dat nesmyslně rozházená do desítek malých tabulek s hromadou vazeb mezi nima, dotaz pro získání 10ti sloupců znamená 7 joinů) není zrovna můj koníček :-D
-
ten tvoj:
SELECT DISTINCT ID from TBL WHERE Vlastnost=A and (Vlastnost=B OR Vlastnost=C)
je na tento ucel presne to co hladas.
To je na nic, tabulka obsahuje páry "jedno ID <-> jedna vlastnost" , takže těžko použiju jakejkoliv výraz obsahující "AND", protože mi nemůže dát nikdy žádný výsledek.
-
+---+----------+
| ID | Vlastnost |
+---+----------+
| 1 | A |
| 2 | A |
| 2 | B |
| 3 | A |
| 3 | C |
+---+----------+
Potrebuji vybrat jen ID, ktere ma prirazenu napr. vlastnost A i B (v tomto pripade ID 2)
select table.id
from table
inner join table as table2 on table2.id=table.id and table2.vlastnost='B'
where table.vlastnost='A'
group by table.id
order by table.id
pripadne rozsirit na noznost vybrat kazde ID, ktere ma A a k tomu B nebo C (v tomto pripade ID 2 a 3).
select table.id
from table
inner join table as table2 on table2.id=table.id and (table2.vlastnost='B' or table2.vlastnost='C')
where table.vlastnost='A'
group by table.id
order by table.id
Většinou pracuju s SQL
S SQL dosud nepracuješ, jinak by pro tebe řešení výše uvedených problémů bylo denním chlebem.
-
Asi jsem dostatečně nezdůraznil, že uvedené možnosti byly pouze příklady, a potřebuji obecnější postup. Jde o to, aby si podmínku vytvořil v jednoduchým klikátku uživatel, který má k dispozici tlačítka "přidat vlastnost" "AND" "OR" "(" a ")" - mohl si naklikat cokoliv, třeba "(A and (B or C) and (D or E)) or G" - prostě cokoliv. Takhle naklikaný výraz potom jednoduše sparsuju PHPčkem do query, který použiju na to view, který jsem si vytvořil.
A ano, uznávám, s SQL nepracuju, spíš ho občas používám.
Jinak mám to sice vyřešený, ale jestli někdo přijde s nějakým elegantnějším řešením, tak ho určitě uvítám :)
-
Asi jsem dostatečně nezdůraznil, že uvedené možnosti byly pouze příklady, a potřebuji obecnější postup. Jde o to, aby si podmínku vytvořil v jednoduchým klikátku uživatel, který má k dispozici tlačítka "přidat vlastnost" "AND" "OR" "(" a ")" - mohl si naklikat cokoliv, třeba "(A and (B or C) and (D or E)) or G" - prostě cokoliv. Takhle naklikaný výraz potom jednoduše sparsuju PHPčkem do query, který použiju na to view, který jsem si vytvořil.
A ano, uznávám, s SQL nepracuju, spíš ho občas používám.
Jinak mám to sice vyřešený, ale jestli někdo přijde s nějakým elegantnějším řešením, tak ho určitě uvítám :)
Elegantní řešení na relační databázi neexistuje - z principu - to, co děláte prostě relační databáze nedělají. Můžete zkusit nerelační databázi - CouchDB, MongoDB, ElasticSearch - a tohle tam bude triviální - případně v Postgresu použít uložení do HStoru a dotazovat se nad HStorem (což je tak v podstatě už nerelační uložení dat).
-
Obecné elegantní řešení na takové obecné dotazování není.
Pomůže při importu uložit výsledek tohoto dotazu do speciální tabulky, řádně oindexovat a dotazy dělat tam.
select coalesce(table.id, table2.id, table3.id) as id, table.vlastnost as vlastnost_a, table2.vlastnost as vlastnost_b, table3.vlastnost as vlastnost_c
full outer join table as table2 on table2.id=table.id and table2.vlastnost='B'
full outer join table as table3 on table3.id=table.id and table3.vlastnost='C'
where table.vlastnost='A'
-
...
nicméně dobré řešení asi neexistuje - způsob jaký používáte se označuje jako EAV a je to známý antipattern - taky proto se Vám s tím špatně dělá.
...
Dlouho jsem s DB nic pořádného nedělal, ale zajímá mne to:
Pavle, co je v tomto případě ten antipattern?
Struktura té tabulky?
A pokud ano, jak by se to mělo řešit správně (mne teď v těch hicech nic nenapadá + viz výše), stačí třeba jen nějaký link na něco k přečtení ...
-
... Jde o to, aby si podmínku vytvořil v jednoduchým klikátku uživatel, který má k dispozici tlačítka "přidat vlastnost" "AND" "OR" "(" a ")" - mohl si naklikat cokoliv, třeba "(A and (B or C) and (D or E)) or G" - prostě cokoliv. ...
Tohle myslis vazne? heh ... to ti nikdy fungovat nebude. A jako bonus vyrobis do systemu diru jak hrom. Nehlede na to, ze stejne nikdy zadny usery ktery neumej psat primo SQL nenaucis to pouzivat. Podotykam, ze podobnou vec ktera se presne o totez snazi adminuju. Defakto to vypada tak, ze ja a kolegove si pisem rovnou SQLko, protoze je to radove rychlejsi nez to, ktery ten bazmek vygeneruje, a useri nezvladaj z 80% udelat ani filtr metodou vyberu pole, zvolim jestli =/like/...
-
...
nicméně dobré řešení asi neexistuje - způsob jaký používáte se označuje jako EAV a je to známý antipattern - taky proto se Vám s tím špatně dělá.
...
Dlouho jsem s DB nic pořádného nedělal, ale zajímá mne to:
Pavle, co je v tomto případě ten antipattern?
Struktura té tabulky?
A pokud ano, jak by se to mělo řešit správně (mne teď v těch hicech nic nenapadá + viz výše), stačí třeba jen nějaký link na něco k přečtení ...
Relační databáze předpokládají, že význam je určený sloupcem - mám sloupec příjmení, mám sloupec jméno. Jakmile se sémantika určuje další hodnotou, nebo několika dalšími hodnotami, tak SQL jako celek přestane fungovat - dotazy přestanou být názorné a čitelné, odhady založené na statistikách budou ustřelovat - a z SQL databáze se stane polofunkční key/value databáze - protože celý ten aparát - SQL, optimalizace, exekuce je navržená na nějaký způsob uložení dat, a pro něj je 30 let optimalizována.
Jak by se to mělo řešit správně - předně, musím si uvědomit, co chci dělat - pokud pracuji s extrémně dynamickými daty, které za pár týdnů zahodím, tak bych asi nepoužil relační databází, ale šel bych do NoSQL databáze - relační databáze, jsou navržené tak, aby dokázaly rychle zpracovat velké množství dat se stabilní strukturou - evidence, sklady, řízení výroby. Pokud ale stabilní strukturu nemám - pracuji s velkým množstvím dynamicky měnících se atributů - vyhledávání v katalogu produktů, atd - tak bych měl použít dokumentovou databázi, která je postavená úplně jinak, a na jiný typ dotazů. EAV je snaha o napsání si vlastní dokumentové databáze - bohužel už je to nad SQL databází a tam už programátor nemá možnost to udělat efektivně.
Pro projekty, které nejsou velké asi budou postačovat extenze do stávajících relačních databází, jako je v Postgresu Jsonb, Hstore, které částečně umožňují kombinovanou práci. U velkých projektů (desítky, spíš stovky GB) je výhodnější použít víc specializovaných databází - finance, majetek řeším v relační SQL db, vyhledávání v katalogu v NoSQL databázi, a cache řeším nějakou paměťovou databází, analytiku pak sloupcovou. Jednak se mi dekomponuje prostředí, druhak díky použití optimalizovaných databází a jazyků nemusím vymýšlet desítky berliček a workaroundů, a každý blok pak je výrazně jednodušší a čitelnější. Nelze si vystačit jenom s jedním stylem - protože jdou proti sobě.
-
Obecné elegantní řešení na takové obecné dotazování není.
Pomůže při importu uložit výsledek tohoto dotazu do speciální tabulky, řádně oindexovat a dotazy dělat tam.
select coalesce(table.id, table2.id, table3.id) as id, table.vlastnost as vlastnost_a, table2.vlastnost as vlastnost_b, table3.vlastnost as vlastnost_c
full outer join table as table2 on table2.id=table.id and table2.vlastnost='B'
full outer join table as table3 on table3.id=table.id and table3.vlastnost='C'
where table.vlastnost='A'
To by fungovalo s malym poctem vlastnosti, ale tech vlastnosti je hodne (cca 200) a jejich pocet se muze menit.
-
Relační databáze předpokládají, že význam je určený sloupcem - mám sloupec příjmení, mám sloupec jméno. Jakmile se sémantika určuje další hodnotou, nebo několika dalšími hodnotami, tak SQL jako celek přestane fungovat - dotazy přestanou být názorné a čitelné, odhady založené na statistikách budou ustřelovat - a z SQL databáze se stane polofunkční key/value databáze - protože celý ten aparát - SQL, optimalizace, exekuce je navržená na nějaký způsob uložení dat, a pro něj je 30 let optimalizována.
dekuji za pekny popis situace :) Databaze, ze ktere to taham neni moje a v podstate mam jen dve moznosti - bud ji celou z SQL predelat na neco jinyho a zpracovavat posleze, nebo udelat nejakou lehkou prasarnu, coz je asi v tomhle pripade jednodussi cesta a moc velky zmatky nehrozi. Databaze neni moc velka (250MB vcetne obrazku v BLOBech) a predpokladam, ze poroste pomaleji, nez vypocetni vykon :D
-
vlastnosti je hodne (cca 200) a jejich pocet se muze menit.
Tak to asi musí být to předchozí řešení s inner joiny a dotaz se musí dynamicky sestavovat podle zadaných podmínek.
-
Relační databáze ...
Díky za nakopnutí.
(Ale pořádně se nad tím zamyslím, až venku nebude 40 ve stínu ...)
-
mozna trosku mimo tema, jak nejlepe sber nasledujicich dat
mam mista kde se sleduji veliciny
CREATE TABLE mista
(
id serial NOT NULL,
nazev text,
CONSTRAINT pk_mista PRIMARY KEY (id)
)
veliciny ktere se sleduji
CREATE TABLE veliciny
(
id serial NOT NULL,
nazev text,
mj character(3),
CONSTRAINT pk_veliciny PRIMARY KEY (id)
)
vazbu mista-veliciny
CREATE TABLE misto_velicina
(
id serial,
id_misto integer,
id_velic integer,
CONSTRAINT pk_misto_velicina PRIMARY KEY (id)
)
a samotna ulozena data
CREATE TABLE cteni
(
id serial NOT NULL,
dt timestamp without time zone ,
id_misto integer NOT NULL,
id_velic integer NOT NULL,
hodnota numeric(8,3),
CONSTRAINT pk_cteni PRIMARY KEY (id)
)
pokud nevim kolik bude mist,kolik bude velicin a kde se bude co sledovat je nejaka lepsi moznost jak mit data ulozena?
a co kdyz budu chtit sledovat i veliciny ktere by nemely ciselnou hodnotu?
mk
-
Tohle myslis vazne? heh ... to ti nikdy fungovat nebude. A jako bonus vyrobis do systemu diru jak hrom. Nehlede na to, ze stejne nikdy zadny usery ktery neumej psat primo SQL nenaucis to pouzivat. Podotykam, ze podobnou vec ktera se presne o totez snazi adminuju. Defakto to vypada tak, ze ja a kolegove si pisem rovnou SQLko, protoze je to radove rychlejsi nez to, ktery ten bazmek vygeneruje, a useri nezvladaj z 80% udelat ani filtr metodou vyberu pole, zvolim jestli =/like/...
Jo, myslim to vazne a funguje to. Neni to nic zase tak zasadniho, jedinej uzivatel bude manzelka, ktere bud ty zavorky a dva operatory vysvetlim, nebo to holt udelam za ni :-D
Jinak to neni zadnej "system", ale jednoucelova aplikace pro presuny a synchronizace dat z databaze dodavatele do e-shopu. Nebavilo me se koukat, jak to manzelka prepisuje vsechno rucne, tak jsem to chtel malinko zautomatizovat. Nejvetsi problem je v tom, ze v puvodni databazi muze byt jedna polozka v libovolnem poctu ruznych kategorii, coz jsem potreboval predelat, idealne na zaklade definice "urcita kombinace kategorii v DB"="jedna kategorie v E-shopu", coz skoncilo na nadefinovani te kombinace kategorii DB (respektive neskoncilo, je to nekonecny, aneb "udelej to jinak, neslo by to takhle, pak to upravime, znovu a lepe")
Navic me celkem zajimalo, jestli to zvladnu i z puvodniho FireBirdu (z ciste vyzkumnych a masochistickych duvodu) bez prevodu cele DB do MySQL. Takze ted je z toho krasnej slepenec HTML/PHP/JS/MySQL/FireBird plnej zakomentovanych slepych vetvi, promenych pokus1 az pokusmilion a ted uz to musim jenom cely uhladit (v tomto pripade spis prepsat) :-D Ale jinak dobry, pekne sem si zablbnul, neco se naucil, par lidi na rootu zamestnal a i pres nazory "to nejde" jsem to dokazal rozchodit. Mam z toho dobry pocit. :-D
-
mozna trosku mimo tema, jak nejlepe sber nasledujicich dat
osobne bych pridal do tabulky "veliciny" polozku "typ", ktera by urcovala, jestli bude velicina ciselna nebo textova a v samotnych datech bych udelal dve pole hodnota_num a hodnota_txt s tim, ze by se zapisovalo vzdy jen do jenoho, pripadne uplne rozdelit tabulku s datama na cteni_num a cteni_txt
jeste me napadlo ukladat velicinu vzdy jako text, s tim, ze uspech konverze text->num by urcil sam o sobe, jakeho typu jsou data, ale mohl by s tim nastat problem, pokud by z nejakeho duvodu hodnota v textove velicine byla cislo (to musis posoudit ty, jestli je to mozne)
Ale jsou tu urcite lepsi lidi na DB a nedokazu realne posoudit, jaky by s tim mohly byt problemy, jak to bude s vykonem pro vetsi mnozstvi dat atd...
-
Relační databáze předpokládají, že význam je určený sloupcem (...)
Jak by se to mělo řešit správně - předně, musím si uvědomit, co chci dělat - pokud pracuji s extrémně dynamickými daty, které za pár týdnů zahodím, tak bych asi nepoužil relační databází, ale šel bych do NoSQL databáze - relační databáze, jsou navržené tak, aby dokázaly rychle zpracovat velké množství dat se stabilní strukturou (...)
Pro projekty, které nejsou velké asi budou postačovat extenze do stávajících relačních databází, jako je v Postgresu Jsonb, Hstore, které částečně umožňují kombinovanou práci (...)
No dobře, to je určitě pravda. EAV je snaha ukládat data s proměnnou strukturou do databáze s neměnnou strukturou. Pak jsem odkázán na to, že sémantiku uložím jako hodnotu. Na druhou stranu se s tím člověk setká opravdu často, skoro v každé databázi, se kterou jsem se setkal, je pár takových tabulek. Jsonb nebo Hstore by pro nově navrhovanou databázi byly asi ideální, akorát nevím, jaká je podpora v ORM nástrojích? Můžete doporučit nějaké zdroje k tomu? Zajímá mě hlavně java.
Sám jsem nedávno vymýšlel jeden takový dynamický EAV, musel jsem přidat přes triggery aktualizované indexové tabulky, aby bylo hledání dost rychlé, následné složení všech dat náležejících k jedné entitě ale zůstalo stále dost pomalé, takže bych měl přidat ještě další tabulku, kde budou data entity pohromadě už připravená... => jinými slovy jsem implementoval něco, co bych u Jsonb nebo Hstore měl už asi automaticky hotové. Existuje tam možnost nějaké validace dokumentů? Cílem by v mém případě bylo, aby část databáze byla dynamicky definovatelná, aby si strukturu mohl uživatel sám nadefinovat a vytvořené dokumenty vůči definici pak validovat.
Uvítám nějaké zdroje k výše řečenému.
-
No dobře, to je určitě pravda. EAV je snaha ukládat data s proměnnou strukturou do databáze s neměnnou strukturou. Pak jsem odkázán na to, že sémantiku uložím jako hodnotu. Na druhou stranu se s tím člověk setká opravdu často, skoro v každé databázi, se kterou jsem se setkal, je pár takových tabulek. Jsonb nebo Hstore by pro nově navrhovanou databázi byly asi ideální, akorát nevím, jaká je podpora v ORM nástrojích? Můžete doporučit nějaké zdroje k tomu? Zajímá mě hlavně java.
Uvítám nějaké zdroje k výše řečenému.
Javě a ORM se vyhýbám obloukem, takže o nich nic nevím. V tuhle chvíli jsou Hstore i Jsonb dost jednoduché typy, které podporují základní operace, a jejich jediná výhoda je, že drží efektivně atributy pohromadě. Pro Jsonb se připravuje několik extenzí, které výrazně zvýší možnost dotazování - http://pgxn.org/dist/jsquery/1.0.0/ a o podpoře schémat (zatím jsou to spíš pokusy https://github.com/petrounias/json-schema-toolkit ) už jsem také slyšel (zatím je k dispozici validace pomocí contraintů a výrazů http://blog.endpoint.com/2013/06/postgresql-as-nosql-with-data-validation.html). Hstore se už rozšiřovat nebude - je to předchozí generace Jsonb
-
Jsonb nebo Hstore by pro nově navrhovanou databázi byly asi ideální, akorát nevím, jaká je podpora v ORM nástrojích? Můžete doporučit nějaké zdroje k tomu? Zajímá mě hlavně java.
V ORM nástrojích typicky je možné definovat vlastní typy, takže tam jen doplníš převod z/do byte[] (nebo stringu, pokud místo jsonb použiješ normální json nebo xml).
Triviální (ale reálný) příklad pro JSON:
@Column(name = "custom_data")
@Lob
@Type(type = "org.codehaus.jackson.node.ObjectNode")
private ObjectNode customData;
-
zrovna před chvílí jsem řešil ten samý problém, konečné funkční řešení pro PHP a MySQL (za použití dibi):
public function getItemIDsBySetupIDs(array $setup_ids)
{
$data = $this->connection
->select('DISTINCT housing_id')
->from('housings_x_setups')
->where('housing_setup_id IN %in', $setup_ids)
->groupBy('housing_id')
->having('COUNT(housing_setup_id) = %u', sizeof($setup_ids))
->fetchPairs('housing_id', 'housing_id');
return $data ?: [0];
}
-
Jsonb nebo Hstore by pro nově navrhovanou databázi byly asi ideální, akorát nevím, jaká je podpora v ORM nástrojích? Můžete doporučit nějaké zdroje k tomu? Zajímá mě hlavně java.
V ORM nástrojích typicky je možné definovat vlastní typy, takže tam jen doplníš převod z/do byte[] (nebo stringu, pokud místo jsonb použiješ normální json nebo xml).
Triviální (ale reálný) příklad pro JSON:
@Column(name = "custom_data")
@Lob
@Type(type = "org.codehaus.jackson.node.ObjectNode")
private ObjectNode customData;
To co popisujes funguje jen pro konverzi BLOB => Java class. Pokud mas nejaky komplexni datavy typ v databazi a chces ho prevest na tridu, tak musis pouzit posledni verze JPA (2.1) - Attribute Converter anebo Entity Listener.
-
a DISTINCT tam bejt nemá :P
-
Javě a ORM se vyhýbám obloukem, takže o nich nic nevím. V tuhle chvíli jsou Hstore i Jsonb dost jednoduché typy, které podporují základní operace (...)
Děkuji Pavlovi Stěhulovi za čerstvé zprávy z bojiště a za odkazy. Postgres je bezvadná databáze a pokud tam začnou fungovat i tyhle věci, bude to skvělé (a až bude ta podpora multicore CPU pro jeden query, bude to ještě lepší).
Jinak by to bylo celé asi na obsáhlou debatu - kdy použít JSON, kdy XML a kdy sáhnout rovnou k objektové databázi. Ale je to přliš široké téma, asi nemá smysl to tady řešit.
-
ten tvoj:
SELECT DISTINCT ID from TBL WHERE Vlastnost=A and (Vlastnost=B OR Vlastnost=C)
je na tento ucel presne to co hladas.
To je na nic, tabulka obsahuje páry "jedno ID <-> jedna vlastnost" , takže těžko použiju jakejkoliv výraz obsahující "AND", protože mi nemůže dát nikdy žádný výsledek.
mas pravdu to som prehliadol.
podla vsetkeho firebirdsql podporuje INTERSECT operator takze tu kveru mozes poskladat takto ():
SELECT ID from TBL WHERE Vlastnost=A
INTERSECT
SELECT ID from TBL WHERE Vlastnost=B
INTERSECT
SELECT ID from TBL WHERE Vlastnost=X
INTERSECT
SELECT ID from TBL WHERE Vlastnost=Z
INTERSECT
(
SELECT ID from TBL WHERE Vlastnost=E
UNION
SELECT ID from TBL WHERE Vlastnost=F
)
to stym E,F by bol ten OR
-
Sám jsem nedávno vymýšlel jeden takový dynamický EAV, musel jsem přidat přes triggery aktualizované indexové tabulky, aby bylo hledání dost rychlé, následné složení všech dat náležejících k jedné entitě ale zůstalo stále dost pomalé, takže bych měl přidat ještě další tabulku, kde budou data entity pohromadě už připravená... => jinými slovy jsem implementoval něco, co bych u Jsonb nebo Hstore měl už asi automaticky hotové. Existuje tam možnost nějaké validace dokumentů? Cílem by v mém případě bylo, aby část databáze byla dynamicky definovatelná, aby si strukturu mohl uživatel sám nadefinovat a vytvořené dokumenty vůči definici pak validovat.
Uvítám nějaké zdroje k výše řečenému.
@Ondrej - ve svych projektech (stredne velke webove aplikace; Java/Hibernate) pouzivam pro bussiness objekty komplexni datove schema zalozene na EAV (genericke atributy bussiness objektu definovane v datech, stromy bussiness objektu, obecne grafy bussiness objektu). Vlastnosti reseni jsou:
* databazi pouzivam pouze jako uloziste dat a logiku ridim v transakci z aplikace (uplne jsem opustil zpusob vytvareni aplikaci na strane DB),
* editace a cteni jednoho objektu trva rozumne dlouho (x1-10ms podle rychlosti DB; DB nejlepe na lokalnim stroji, protoze precteni jednoho objektu znamena vice dotazu; pocet dotazu zavisi na architekture datoveho modelu),
* pro publikaci objektu (renderovani stranky) mam k dispozici nakesovane objekty, takze rychlost jejich pouziti je ekvivalentem pouziti POJO,
* synchronizace kese objektu a DB se deje v ramci modifikace objektu pomoci servisni vrstvy, ktera se postara o zneplatneni polozek v kesi.
* 2 mody pristupu k objektum: cteni a editace.
* Vyhodou je pouzivani pouze relacni DB pro veskera ulozena data a tim nesporna vyhoda prace v jedne reansakci.
* Zdanlivou nevyhodou tohoto pristupu je, ze se data musi vejit do pameti. Pokud ale ma byt DB svizna, musi splnovat stejny pozadavek.
Jadro, ktere se o to stara, je relativne male (cca 20.000 radek kodu) a dovoluje mi vyvoj datoveho modelu s prakticky neomezenenou slozitosti a to diky tomu, ze jsem pro tento specialni pripad uspokojive vyresil dva protichudne pozadavky. Cela jedna aplikace je uz nasobne vetsi.
Odezvy na webu jsou vytecne. Az na vyjimky (velke stranky) vzdy do 100ms, prumer cca 50ms.
Raskal
-
* Zdanlivou nevyhodou tohoto pristupu je, ze se data musi vejit do pameti. Pokud ale ma byt DB svizna, musi splnovat stejny pozadavek.
Jenomže relační databáze pracuje s pamětí výrazně efektivněji - a pokud jí paměť dojde, tak při dobře navrženém schématu neztratí výkon fatálně - resp - celá ta technologie je navržena tak, aby fungovala i s relativně malou pamětí - samozřejmě, nesmíte používat EAV.
-
@Ondrej - ve svych projektech (stredne velke webove aplikace; Java/Hibernate) pouzivam pro bussiness objekty komplexni datove schema zalozene na EAV ...
... Jadro, ktere se o to stara, je relativne male (cca 20.000 radek kodu) ...
Takové rozežrané jádro je relativně malé?
Odezvy na webu jsou vytecne. Az na vyjimky (velke stranky) vzdy do 100ms, prumer cca 50ms.
Raskal
Supluje to SQL, tak se nediv, že je to tak líné.
-
* Zdanlivou nevyhodou tohoto pristupu je, ze se data musi vejit do pameti. Pokud ale ma byt DB svizna, musi splnovat stejny pozadavek.
Jenomže relační databáze pracuje s pamětí výrazně efektivněji - a pokud jí paměť dojde, tak při dobře navrženém schématu neztratí výkon fatálně - resp - celá ta technologie je navržena tak, aby fungovala i s relativně malou pamětí - samozřejmě, nesmíte používat EAV.
Ano, sql databaze jsou pametove efektivnejsi, je to ale jen linearni parametr toho celeho systemu. Pametova zavislost aplikace je linearne zavisla na pametove narocnosti databaze a zaroven aplikace nemusi mit uplne vsechna data permanentne v pameti. Mam-li napriklad 5GB dat v DB, aplikace je cca 10x narocnejsi, ale potrebuje z toho permanentne kesovat jen 1GB dat z DB, tak se mozna vejdu i do 16GB RAMky.
-
@Ondrej - ve svych projektech (stredne velke webove aplikace; Java/Hibernate) pouzivam pro bussiness objekty komplexni datove schema zalozene na EAV ...
... Jadro, ktere se o to stara, je relativne male (cca 20.000 radek kodu) ...
Takové rozežrané jádro je relativně malé?
Odezvy na webu jsou vytecne. Az na vyjimky (velke stranky) vzdy do 100ms, prumer cca 50ms.
Raskal
Supluje to SQL, tak se nediv, že je to tak líné.
Ano, 20k radku kodu povazuji za maly kus kodu vzhledem ke sluzbe, kterou poskytuje.
50ms odezvu webove aplikace povazuji za vytecnou a nikoliv za "líné". Vystup kazde stranky je potencialne unikatni a nekesuje se.
-
Obvyklé řešení je založené na vícenásobném selfjoinu, které by mělo být docela rychlé pokud podmínkám bude odpovídat tak do 3% řádků. Potom už asi může být rychlejší scan s HAVING.
Jedná se o synchronizaci dat mezi databází dodavatele a e-shopem, která probíhá max 1x denně a jedná se o pár tisíc položek (z nichž se dál zpracovává jen pár set) Trvá to v řádu vteřin a nějaký výrazný skokový nárust objemu dat se nedá očekávat, takže zatím je to v pohodě.
Ale děkuji, aspoň jsem o něco chytřejší. Většinou pracuju s SQL jen v rámci vlastních projektů a datový modely si vytvářím tak, aby to bylo co nejpohodlnější a nejrychlejší na používání. Zpracování cizích databází (a ještě doprasených, většina dat nesmyslně rozházená do desítek malých tabulek s hromadou vazeb mezi nima, dotaz pro získání 10ti sloupců znamená 7 joinů) není zrovna můj koníček :-D
Pokud je to jen par tisic radek, tak proc celou tabulku nenacpete do pameni a pak pouzit jen key, value dotazy na strukturu v pameti?
Pripada mi to v tuto chvili efektivnejsi, nez pouziti sql dotazu.
-
* databazi pouzivam pouze jako uloziste dat a logiku ridim v transakci z aplikace
Dosud jsi se nesetkal s větším projektem, zatím jsou to školní úlohy.
Jakákoliv prakticky nasazená reálná úloha skončí tak že se z nutnosti začnou vytvářet stored procedure na SQL serveru, následně ORM a Hibernate se tak stanou těžko použitelnými. Může se to obkecávat jak dlouho chce, stejně se to vždy stane.
-
podla vsetkeho firebirdsql podporuje INTERSECT operator takze tu kveru mozes poskladat takto ():
kdyz jsem tohle videl, skoro jsem se zaradoval, ale bohuzel, firebird intersect nepodporuje (alespon ne v posledni stable verzi).
-
Upraveno, otestováno, řešení s naskládáním parametrů do BLOBu v nově vytvořeném VIEW funguje pro moje potřeby dostatečně dobře. V podstatě by mě zajímalo řešení, jak to udělat bez toho nového VIEW (nevím, jestli to celý jde nějak naskládat do nějakýho jednoho selectu klidně s dalšíma vloženýma).
Co se týče různých profi řešení nahrát to celý do paměti a podobně, nápady jsou to pěkný, ale celý je to na virtuálu, kde toho běží víc a na takový fórky tam opravdu není HW a nebudu ho kvůli tomuhle řešit :-)
A co se týče přístupu Kolemjdouciho, "všichni jsou amatéři, já jedinej tu dělám s velkýma DB a já jedinej to umím dobře", tak k tomu nemám slov. Přiměřený funkční řešení odpovídající situaci nevymyslí, protože i když existuje (a jsem presvědčenej o tom, ze jich je víc a že nějaké hezčí ještě najdu i když už v podstatě o nic nejde), tak je asi moc deformovanej podnikovým prostředím na to, aby dokázal vytvořit řešení pro obyčejný lidi. Vidím to v práci, RAM, CPU a disky přihazuju do serverů pomalu vidlema, protože co chvíla přijde někdo z vývoje s tím, že něco předělává, aby to běželo o 10 procent rychleji a stačí mu k tomu jenom dvakrát víc jader CPU a 4x víc RAMky. Jestli jste si nevšiml, jedná se o malej projekt, nejedná se o žádnej kritickej systém s tisícema paralelních přístupů a nevydělá si to ve výsledku ani na kafe, který u něho vypiju, natož na cokoliv jinýho.
-
To je nedorozumění, odpověď byla pro Raskal.
Univerzální optimální řešení problému Tuxik v SQL DB není dosud známo, neznají ho ani sami tvůrci SQL DB. Procházení všech řádků tabulky pořád znovu je funkční, ale ne optimální.
-
Jakákoliv prakticky nasazená reálná úloha skončí tak že se z nutnosti začnou vytvářet stored procedure na SQL serveru, následně ORM a Hibernate se tak stanou těžko použitelnými. Může se to obkecávat jak dlouho chce, stejně se to vždy stane.
Konečně něco, s čím mohu plně souhlasit.
-
Jsonb nebo Hstore by pro nově navrhovanou databázi byly asi ideální, akorát nevím, jaká je podpora v ORM nástrojích? Můžete doporučit nějaké zdroje k tomu? Zajímá mě hlavně java.
V ORM nástrojích typicky je možné definovat vlastní typy, takže tam jen doplníš převod z/do byte[] (nebo stringu, pokud místo jsonb použiješ normální json nebo xml).
Triviální (ale reálný) příklad pro JSON:
@Column(name = "custom_data")
@Lob
@Type(type = "org.codehaus.jackson.node.ObjectNode")
private ObjectNode customData;
To co popisujes funguje jen pro konverzi BLOB => Java class. Pokud mas nejaky komplexni datavy typ v databazi a chces ho prevest na tridu, tak musis pouzit posledni verze JPA (2.1) - Attribute Converter anebo Entity Listener.
Jo, pravda, tohle nebude stačit pokud chci opravdu používat ORM, tedy podle jednotlivých položek uvnitř komplexního typu hledat nebo je dynamicky donačítat podle potřeby. Na druhou stranu, právě tato napsané aplikace jsou důvodem, proč všude vidíš lidi co před ORM varují (zde například Pavel Stěhule a Kolemjdoucí).
Osobně se mi osvědčilo použít ORM jen pro konverzi dat a základní CRUD a pro jakékoliv složitější věci stejně psát konkrétní SQL dotazy (a DDL samozřejmě vždy dělat ručně, resp. nechat si vygenerovat základ a pak dotahnout). Tedy v podstatě spíš iBatis (myBatis) přístup. Lze použít i pro Hibernate/JPA, ale vyžaduje disciplínu.
-
* databazi pouzivam pouze jako uloziste dat a logiku ridim v transakci z aplikace
Dosud jsi se nesetkal s větším projektem, zatím jsou to školní úlohy.
Jakákoliv prakticky nasazená reálná úloha skončí tak že se z nutnosti začnou vytvářet stored procedure na SQL serveru, následně ORM a Hibernate se tak stanou těžko použitelnými. Může se to obkecávat jak dlouho chce, stejně se to vždy stane.
Backendy pro Webove aplikace navrhuji a implementuji profesionalne jiz pres 10 let a mam za sebou vyvoj nekolika velkych projektu s navstevnosti okolo 100.000 denne.
Tvoje tvrzeni povazuji za nespravne. K tomu, co jsem zde napsal, me vedou prave dluhodobe zkusenosti a implementace existujicich projektu.
-
Jestliže nedošlo na ručně psané SQL anebo stored procedure na serveru, dosud jsi neměl tu čest s velkým reálným projektem, stane se to vždy, je to jistota jako že ráno vyjde Slunce. Dál se k tomu nevyjadřuji.
-
A nestačilo by prostě tohle?
SELECT DISTINCT id FROM tabulka WHERE attribut = 'a' AND id IN (SELECT id FROM test WHERE attribut <> 'a') ORDER BY id
-
Sakra správně má být
SELECT DISTINCT id FROM test WHERE attribut = 'a' AND id IN (SELECT id FROM test WHERE attribut <> 'a') ORDER BY id
-
Jestliže nedošlo na ručně psané SQL anebo stored procedure na serveru, dosud jsi neměl tu čest s velkým reálným projektem, stane se to vždy, je to jistota jako že ráno vyjde Slunce. Dál se k tomu nevyjadřuji.
Trochu nanic příspěvek. Pokud byste uvedl příklady ze své praxe, posloužil byste lépe sobě i ostatním. Správně byste měl uvést segment, kde se pohybujete (jaké projekty rozsahem, typem, pro koho a s jakou životností) a jaké tam jsou zvyklosti. Asi byste zjistil, že segment Raskala je jiný a že tam je prostě jiná praxe. A nemusí jít zrovna o školní úlohy.
No a po technické stránce není stored procedure jako stored procedure - v některých případech může fungovat s ORM bez problémů. Každé rozumné ORM navíc umožňuje používat holé sql, čímž se stírá rozdíl ORM/neORM a lze se tím vyhnout nevýhodám obojího a spojit výhody obojího. Tož asi tak.
-
... Každé rozumné ORM navíc umožňuje používat holé sql, čímž se stírá rozdíl ORM/neORM a lze se tím vyhnout nevýhodám obojího a spojit výhody obojího. Tož asi tak.
ORM je stejně jen berličkou pro ty, kteří SQL neumí. Kombinací ORM a SQL vznikne kočkopes, který věčně válčí se špinavou cache.
-
Trochu nanic příspěvek.
Nanic je každá diskuze o užitečnosti ORM ve spojitosti s SQL DB. Komu se z nějakého důvodu líbí styl práce s daty, nechť použije vhodnější NoSQL, nemusí se zdržovat ani s ORM ani s SQL DB.
-
Nanic je každá diskuze o užitečnosti ORM ve spojitosti s SQL DB. Komu se z nějakého důvodu líbí styl práce s daty, nechť použije vhodnější NoSQL, nemusí se zdržovat ani s ORM ani s SQL DB.
Tak zaprve záleží, jestli si můžete vybrat. Když si vybrat nemůžete a máte ORM daný, potřebujete o tom co nejvíc vědět, abyste nedojel na naivní použití. A když si vybrat můžete, potřebujete taky co nejvíc vědět, abyste si správně vybral :-D
Jinak, když už něco jiného. tak rovnou objektovou databázi.
-
Jestliže nedošlo na ručně psané SQL anebo stored procedure na serveru, dosud jsi neměl tu čest s velkým reálným projektem, stane se to vždy, je to jistota jako že ráno vyjde Slunce. Dál se k tomu nevyjadřuji.
Segment webovych aplikaci je narocny na optimalizaci a to predevsim databaze na backendu (nejen SQL a DDL, ale i DB stroje). A nejak si nedovedu predstavit praci s ORM bez znalosti SQL. Kazdy, kdo chce pouzivat ORM, by mel SQL znat alespon na takove urovni, aby vedel, co mu to ORM generuje za dotazy. Co pises, je nicim nepodlozene tvrzeni, ktera je v rozporu s tim, co jsem napsal v jednom z nimulych prispevku: "Backendy pro Webove aplikace navrhuji a implementuji...". Navrh a optimalizace DB schematu je soucasti me prace. S ORM jsem se uspesne preklenul pres to, abych psal kazde sql pouzite v aplikaci. Dost spatne se refaktoruje aplikace, ktera ma v sobe x100 zadratovanych SQL prikazu a nektere z nich je treba utvaret dynamicky v zavislosti na datech. Vhodne pouziti ORM tento problem eliminuje a dovoluje se soustredit na reseny problem. Zpusob psani aplikaci na strane DB je, podle meho narozu, zastaraly a nepruzny. SQL a PL/SQL na to nejsou vhodne nastroje, ackoliv bylo dostatek snahy aby byly. Presne timto zpusobem psani aplikaci jsem zacal nekdy cca pred 15 lety a dosel jsem k tomu, ze vyuzivam sluzeb ORM. ORM je nastroj a jako takovy se musi pouzivat spravne, jinank je to ke skode. Toto je hlavni problem proc na nej lidi nadavaji - neznalost a nevhodne pouziti.
Chce to trochu nadhledu a mene do ostatnich kopat.
-
Tak zaprve záleží, jestli si můžete vybrat. Když si vybrat nemůžete a máte ORM daný, potřebujete o tom co nejvíc vědět, abyste nedojel na naivní použití. A když si vybrat můžete, potřebujete taky co nejvíc vědět, abyste si správně vybral :-D
Pokud mám ORM dané, tak stejně nebudu vědět nic, protože na rozdíl od SQL k tomu není žádná univerzální dokumentace. Takže o ORM nepotřebuji vědět vůbec nic - zkušenosti z jednoho ORM u jiného ORM nevyužiji.
A pokud si vybrat můžu, tak jednoznačně SQL. Je fakt, že mezi jednotlivými implementacemi jsou velké rozdíly - např. hstore z PostgreSQL by se jako řešení dotazu velmi dobře hodil, ale Firebird tím nedisponuje. Vůbec však netuším, které ORM podporuje hstore a které ne. A je mi to jedno, protože s ORM dělat nebudu.
-
Dost spatne se refaktoruje aplikace, ktera ma v sobe x100 zadratovanych SQL prikazu a nektere z nich je treba utvaret dynamicky v zavislosti na datech.
SQL dotazy mají v aplikaci své místo a není tedy problém s refaktorováním ani dynamickým generováním. Pokud některé z nich jsou implementačně závislé (každý zákazník to chce jinak), umístím je do databáze.
-
... Každé rozumné ORM navíc umožňuje používat holé sql, čímž se stírá rozdíl ORM/neORM a lze se tím vyhnout nevýhodám obojího a spojit výhody obojího. Tož asi tak.
ORM je stejně jen berličkou pro ty, kteří SQL neumí. Kombinací ORM a SQL vznikne kočkopes, který věčně válčí se špinavou cache.
To, co to ORM dela je pevne v rukou vyvojare. Pokud ho spatne pouzijes, pak se spatne chova.
Spinava cache je ve vsech distribuovanych systemech, ktere porizuji kopii dat urcenou ke cteni a modifikaci, takze to nelze pricitat specielne k problemum ORM.
Souhlasim s tim, ze tandem DB + ORM neni stastne reseni. Bohuzel se za tech nekolik desitek let do RDBMS nainvestovalo tolik, ze se i dnes vyplati je pouzivat. Lepsi by bylo nemit ORM vrstvu, ale zaroven mit k dispozici objekty (resp. funkce) bez zbytecne mezivrstvy. Bohuzel neznam zadny takovy produkt, ktery by tento handicap odstranoval a zaroven zachoval vyhody, ktere mainstreamove relacni DB poskytuji.
-
Pokud mám ORM dané, tak stejně nebudu vědět nic, protože na rozdíl od SQL k tomu není žádná univerzální dokumentace. Takže o ORM nepotřebuji vědět vůbec nic - zkušenosti z jednoho ORM u jiného ORM nevyužiji.
A pokud si vybrat můžu, tak jednoznačně SQL. Je fakt, že mezi jednotlivými implementacemi jsou velké rozdíly - např. hstore z PostgreSQL by se jako řešení dotazu velmi dobře hodil, ale Firebird tím nedisponuje. Vůbec však netuším, které ORM podporuje hstore a které ne. A je mi to jedno, protože s ORM dělat nebudu.
Ještě byste byl rád za ORM - konkrétní ORM nástroj naopak představuje standard, který je výhrou v porovnání s lepením sql jak koho při psaní té nebo oné applikace napadlo.
-
(...) Spinava cache je ve vsech distribuovanych systemech, ktere porizuji kopii dat urcenou ke cteni a modifikaci, takze to nelze pricitat specielne k problemum ORM.
Souhlasim s tim, ze tandem DB + ORM neni stastne reseni. Bohuzel se za tech nekolik desitek let do RDBMS nainvestovalo tolik, ze se i dnes vyplati je pouzivat. Lepsi by bylo nemit ORM vrstvu, ale zaroven mit k dispozici objekty (resp. funkce) bez zbytecne mezivrstvy. Bohuzel neznam zadny takovy produkt, ktery by tento handicap odstranoval a zaroven zachoval vyhody, ktere mainstreamove relacni DB poskytuji.
No a zkoušel jste nějaké objektové databáze? V době, kdy se už docela běžně používá map-reduce apod. by mohly bok po boku NoSQL databází proniknout do praxe, ne?
-
No a zkoušel jste nějaké objektové databáze? V době, kdy se už docela běžně používá map-reduce apod. by mohly bok po boku NoSQL databází proniknout do praxe, ne?
Objektove DB jsem par zkusil a jsou samozrejme nejlepe vyhovujici, protoze zde neni zbytecna mezivrstva.
Zakaznikovi se neda jen tak predat projekt udelany nad jinou nez mainstreamovou DB, protoze ho pak casto bude udrzovat nekdo jiny a kolik vyvojaru dobre ovlada nejakou objektovou DB...
Map-reduce a NoSQL resi jine kategorie problemu nez zminuji a uz treba s transakcema a integritnimi omezenimi to neni zrovna v poradku. Zkousel jste nad map-reduce navrhnout datove schema treba inzertniho serveru nebo eshopu, ktery je jako komercni reseni minen zcela vazne? Ja myslim, ze to zatim neni dost dobre mozne. Do toho dynamicky vyvoj datoveho modelu a jeho refaktoring. A i kdyby to bylo mozne (spise akademicka predstava), tak na to ja ani zakaznik nema kapacity.
-
To, co to ORM dela je pevne v rukou vyvojare. Pokud ho spatne pouzijes, pak se spatne chova.
K ORM není ani pořádný manuál, tak jak ho mohu použít správně? Vidím ho jen jako zbytečnou mezivrstvu, která hází vývojáři klacky pod nohy a nutí ho učit se nový jazyk, který není nijak ustálený.
Spinava cache je ve vsech distribuovanych systemech, ktere porizuji kopii dat urcenou ke cteni a modifikaci, takze to nelze pricitat specielne k problemum ORM.
Proto je lepší vyhnout se zbytečnému pořizování kopií dat. SQL databáze mají mnohem lepší cache, které nemusím nijak hlídat.
Souhlasim s tim, ze tandem DB + ORM neni stastne reseni. Bohuzel se za tech nekolik desitek let do RDBMS nainvestovalo tolik, ze se i dnes vyplati je pouzivat. Lepsi by bylo nemit ORM vrstvu, ale zaroven mit k dispozici objekty (resp. funkce) bez zbytecne mezivrstvy. Bohuzel neznam zadny takovy produkt, ktery by tento handicap odstranoval a zaroven zachoval vyhody, ktere mainstreamove relacni DB poskytuji.
Lepší je nemít ORM vrstvu a s relačními daty v relační databázi pracovat relačně. Ta objektová mezivrstva je zbytečná i z toho důvodu, že jen málo vývojářů programuje skutečně objektově...
-
Objektove DB jsem par zkusil a jsou samozrejme nejlepe vyhovujici, protoze zde neni zbytecna mezivrstva.
Zakaznikovi se neda jen tak predat projekt udelany nad jinou nez mainstreamovou DB, protoze ho pak casto bude udrzovat nekdo jiny a kolik vyvojaru dobre ovlada nejakou objektovou DB...
Map-reduce a NoSQL resi jine kategorie problemu nez zminuji a uz treba s transakcema a integritnimi omezenimi to neni zrovna v poradku. Zkousel jste nad map-reduce navrhnout datove schema treba inzertniho serveru nebo eshopu, ktery je jako komercni reseni minen zcela vazne? Ja myslim, ze to zatim neni dost dobre mozne. Do toho dynamicky vyvoj datoveho modelu a jeho refaktoring.
Ne, nezkoušel jsem to. Zajímaly by mě právě spíš objektové databáze než NoSQL. Co jste zkoušel a v čem byly v reálu problémy? Já dělám samé malé projekty, které když neudržuju sám tak neudržuje už nikdo, takže bych to klidně vyzkoušel, pokud by to nemělo moc těžkou učební křivku.
-
Ne, nezkoušel jsem to. Zajímaly by mě právě spíš objektové databáze než NoSQL. Co jste zkoušel a v čem byly v reálu problémy? Já dělám samé malé projekty, které když neudržuju sám tak neudržuje už nikdo, takže bych to klidně vyzkoušel, pokud by to nemělo moc těžkou učební křivku.
Co si vzpominam, tak jsem zkousel Db4o, GemStone/S a Versant Object Database.
https://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems (https://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems)
Odradilo me vetsinou to, ze to neni open source a ze jsem nebyl schopen resit pokrocile problemy, ktere mam vyresene pro nastroje nad relacni DB. Mam hodne malo volneho casu, takze jsem to brzy vzdal..