Dotaz: Katalog zboží v DB

[Tomáš Urban]

Zdravím! Měl bych jeden dotaz. Mám zboží o různých parametrech (např. u jednho druhu zboží se měří průměr a délka, u druhého průměr1, průměr2 a délka,....) Jak nacpat zboží do jedné tabulky? Děkuji za pomoc! TU.

Odpovědi

[Michall]

Viděl jsem v praxi takovouto "prasarnu", ale jejím příznivcem nejsem:

tabulka bude vypadat cca takto:

int id_zbozi

varchar nazev

.

.

.

varchar parametry

 

a potom v parametrech budeš zaznamenávat více hodnot a oddělovat je od sebe nějakých oddělovačem - např středník nebo |

 

Takže záznam do pole parametry vložíš např toto: "delka=55cm|prumer=10cm|vaha=10kg" - zpět z toho to dostaneš např pomocí php funkce explode

 

 

 

 

[s0]

na to snad jen: nedělejte to tak. Nikdy (existuje pár výjimek, ale ty by využil člověk, který takový dotaz nepokládá). ;)

Buď to holt rozdělí do více tabulí (produkty, parametry, popř. další definice_parametrů atd.) nebo nechť použije DBMS, který umí třeba nested tables.

[pht]

A co se na SQL vykašlat a nacpat to do LDAPu, který tohle umí normálně.

[Josef Kufner]

To je docela zajímavá myšlenka, zkoušel jsi to (nebo něco podobného) někdy?

[pht]

Přímo katalog zboží ne, ale jinak s LDAPem mám dost dobré zkušenosti.

[Josef Kufner]

A nechceš trošku povyprávět, jak vypadá použití LDAPu na něco jiného než je adresář kontaktů?

[pht]

Nějak nechápu proč by měl LDAP být jen na adresář kontaktů? Přijde mi, že lidi rádi odstrkují LDAP kamsi do kouta, částečně asi z nepochopení jeho funkcionality.

U toho katalogu zboží bych udělal třeba objectClass=hrnec, atributy objem a průměr, a pak třeba objectClass=pračka, atributy otáčky za minutu. Protože mám dědičnost, tak můžu zadefinovat nějaký generický class pro výrobek kde bude třeba cena, dostupnost. Název zboží budu cpát do cn, např. cn=überpračka. Pak si můžu dělit zboží do kategorií přes groupOfUniqueNames=vaření nebo spotřebiče.

Jestli v tom vidíte nějaký principiální problém, tak ho napište a můžeme se s ním zkusit poprat.

[Josef Kufner]

Tohle by šlo, ale co třeba když pak ke každé pračce budeš chtít přiřazovat nějaké tagy? Dejme tomu, že budeš chtít definovat strom tagů (to není problém) a jednotlivé tagy přidělovat pračkám, kdy každá pračka může mít tagů více (klasická vazba m:n). Vrtá mi hlavou, jak pak efektivně vyhledávat. Jak se LDAP popere s dotazem na pračky, které mají přidělenu nějakou kombinaci tagů?

V sql to muze vypadat cca takle (a je to celkem rychlé):

select p.*
from Pračky, PrideleniTagu pt
where pt.id_pracky = p.id_pracky and pt.id_tagu in (1,2,3,4,5)
group by p.id_pracky
having count(pt.id_tagu) = 5

[pht]

Moc nerozumím k čemu to má být prakticky dobré, dejte nějaký konkrétní příklad? Ten SQL mi najde co? Všechny pračky, které mají tagy 1,1,1,1,1 a 1,1,1,1,2 atd. ?

[Josef Kufner]

Asi by to chtelo dodat, ze v tabulce PrideleniTagu je primarni klic dvojice id_tagu a id_pracky. Vrati to vsecky pracky, ktere maji vsecky tagy.

[pht]

Tak takový filtr lze v LDAPu vytvořit samozřejmě také... jen nějak nechápu jaký je rozdíl mezi tagem pračky a např. její šířkou? V LDAPu to bude obojí atribut objektu (atributů se stejným názvem, např "tag" můžu mít několik).

[AraxoN]

Mňa by zaujímalo, či LDAP podporuje aj hľadanie typu väčší-menší - napríklad keby som chcel vylistovať všetky práčky so šírkou do 45cm (malá kúpeľňa :)), ako by som urobil query? S LDAPom som nikdy nerobil a dogooglil som sa len ku podmienkam na ekvivalenciu a wildcard, čo na takýto prípad IMO nestačí.

[pht]

Podporuje, normálně napíšete do filtru šířka<=45. Pokud budete chtít tohle vyhledávání dělat často, lze LDAPu říct, aby si na ten atribut zřídil index pro vyhledávání typu väčší-menší ...

[s0]

pochlub se. Vážně.

[pht]

Čím?

[happy barney]

s dobrými skúsenosťami a praktickým využitím LDAPu asi, na to s0 reaguje.

[pht]

No ale nějak nechápu jak. Ano - mám dobré zkušenosti - když jsem narazil na úlohu která se dobře řeší LDAPem, tak jsem to v něm dobře vyřešil. Konkrétně se jednalo o organizaci uživatelských rolí a přístupových práv. Další populární využití je autentizace a centrální správa uživatelů. Ale to neznamená, že by v tom nešlo dělat nic jiného. Stačí nadefinovat příslušné schema, asi jak definujete tabulky v SQL. Na programování máte připravené API snad ve všech populárních jazycích. My jsme využili PHP a Perl. K PHP musím podotknout, že to API je trochu retardované, ale to je spíš problém toho, že PHP je retardované :)

Jinak jak jsem říkal, spíš mám z reakcí dojem, že lidi moc LDAP neznají, to by pak chtělo si něco přečíst. Odsouvat LDAP do kouta, že je vhodný jen na kartotéku, je jako tvrdit o SQL že je vhodné jen na kartotéku. Jsou to dva komplementární přístupy k organizaci dat. SQL má tabulky a sloupce, LDAP má stromy a atributy. Záleží, jakou máte úlohu. Někdy lze kombinovat oboje, ostatně existují LDAP backendy které drží data v SQL.

[happy barney]

to máte pravdu, LDAP nie je moc známy. Na SQL nováčik narazí oveľa skôr, niečo sa zbastlí, a aj tých článkov v češtine je o SQL rádovo viac ...

[Karel Benák]

Muhehe o LDAPu jsem kdysi hodně věděl, ale dělat v něm katalog zboží je ... podle mého názoru trošku silná káva. Ne že by to nešlo, to samozřejmě ano, ale je dobré si uvědomit, že např. v LDAPu nepodržíte referenční integritu, budete muset hodně zapracovat na objectclassech apod. Ale když se udělá dobré mapování a architektura (objednávky v SQL, katalog v LDAP, konekce ke dvěma různým serverovým službám) ... proti gustu žáný dišputát.

[pht]

nepodržíte referenční integritu

A na co bych ji měl potřebovat?

hodně zapracovat na objectclassech

V SQL zase na tabulkách.

[Karel Benák]

A na co bych ji měl potřebovat?

Na takovou drobnost jakou je rozšíření katalogu o objednávkový systém. Dělat jej v LDAPu je trošku nepraktické a pracné.

[pht]

Chápu. Ale první zadání byl katalog samotný. Pokud budu mít jiné zadání, budu mít i jiné řešení. Změnou zadání můžu vždy sabotovat jakékoliv řešení, třeba i to SQL.

Jinak, objednávky v LDAPu bych si představit dokázal a pracné to není, jen je potřeba myslet jiným způsobem než u SQL. Pokud bych dělal hybridní řešení LDAP+SQL, tak integrita mezi těmito podsystémy není a priori problém LDAPu ani SQL, ale té spojovaci vrstvy, která by tu integritu nějak musela implementovat. I to bych si dokázal celkem jednoduše představit.

[Josef Kufner]

Změnou zadání můžu vždy sabotovat jakékoliv řešení.

Vítej ve skutečném světě

[kaaja]

Tak to už je lepší udělat si číselník parametrů a pak tabulku, kde bude odkaz na zboží, na parametr a pak jeho hodnota. Na zobrazování to stačí, ale vyhledávat je prasárna.

[moira]

vyhledávat je prasárna

Zalezi co pouzivas za nastroje, trebas ORM te od toho celkem odstini...

[Josef Kufner]

Neodstíní. Pokud chceš vytáhnout z databáze jeden záznam tak možná, ale jakmile budeš chtít vypsat záznamy požadovaných rozměrů (např. delší než X cm) z tabulky o 1000 záznamech (což je celkem málo), tak s ORM končíš. Nemluvě o tom, že by se tam mohl ještě připlést nějaký ten join...

Doporučuju rozhození do dvou tabulek, v jedné zboží v druhé parametry. Případně třetí s typama parametrů.

[moira]

Pokud chceš vytáhnout z databáze jeden záznam tak možná, ale jakmile budeš chtít vypsat záznamy požadovaných rozměrů (např. delší než X cm) z tabulky o 1000 záznamech (což je celkem málo), tak s ORM končíš. Nemluvě o tom, že by se tam mohl ještě připlést nějaký ten join...

Tak ono ta vazba M:N je tam opravdu zbytecna (jsem si to musel asi trikrat precist, nez mi to doslo, ze navrh nebyl na 1:N), ale nevim proc bych mel koncit u 1000 (chapu, ze to je priklad...) zaznamu?

[happy barney]

Pretože ORM nástroje prácu z DB iba zjednodušujú, nezefektívňujú. Spomínaný príklad je možné zapísať rôzne:

 - OO s overloadingom operatorov
result = Katalog.search (Katalog.dlzka >= 1000 && Katalog.hmotnost < 200)

 - textovými konštantami a štruktúrami jazyka
result = Katalog.search ('dlzka' => { '>=', 1000 }, 'hmotnost' => { '<', 200)

 - OO s metódami (fuj)
result = Katalog.search (Katalog.dlzka.greater_or_equal_then (1000).and (Katalog.hmotnost.less_then (200))

Nevraviac o tom, že len niektoré ORM podporujú tento typ namapovania.

A výsledné SQL? Od načítania celých tabuliek a porovnávania v používanom jazyku, cez tie lepšie, ktoré vytiahnu Katalog (buď cez dynamický in alebo fetch per id) podľa prieniku (dlzka >= 1000) a (hmostnost < 200) až po tie najlepšie, ktoré majú k dispozícii "fetch_from_sql"

[Filip Jirsák]

Pretože ORM nástroje prácu z DB iba zjednodušujú, nezefektívňujú.

V mnoha případech ji dokonce zneefektivňují (z pohledu efektivnosti dotazů).

[pavlix]

Asi záleží na tom, jaké ORM

[happy barney]

všetky, okrem "Best ORM ever", ale to som ani nenašiel, ani nenapísal

[pht]

No, ten join snad není takové neštěstí?

SELECT 
    * 
FROM
    produkt
INNER JOIN
    atribut ON atribut.id_produktu = produkt.id
WHERE
    atribut.jmeno = 'delka' AND atribut.hodnota > 100
;

[Josef Kufner]

Join v kombinaci s ORM, kdy není join přímo vestavěn v selectu schovaném pod ORM.

[kaaja]

Jiste, ale pokud chceš hledat podle vice parametru, tak pripojujes tu tabulku mnohokrat a to je svinstvo. Vim dost o cem mluvim, dělám s tímto datovým modelem denne :(

 

[Josef Kufner]

Ale v případě, kdy neznáš dopředu strukturu dat, není moc na výběr. Nebo víš o nějaké lepším způsobu? Taky by se mi hodil

Více joinů většinou není problém... dají se celkem lehce vygenerovat a při dobře udělaných indexech se databáze ani moc nezadýchá. Ale je celkem protivné, že ty dotazy se pak nevejdou na obrazovku...

[blondak]

a co třeba nějak takto (odzkoušeno na MySQL)

SELECT product_id, count(param_id) as params_count FROM `param_table` WHERE
   ( param_id = 1 and param_value >= 150)
OR ( param_id = 2 and param_value > 150)
group by product_id
HAVING params_count = 2 

param_id je ID parametru

CREATE TABLE `param_table` (
  `product_id` int(11) NOT NULL,
  `param_id` int(11) NOT NULL,
  `param_value` varchar(50) NOT NULL
);

protože mysql dělá konverzi typů, dá se to takto použít, pak jenom podle param_id vybrat vhodný operátor.

[blondak]

jenom doplním, že v klauzuli HAVING params_count = 2 se musí params_count rovnat počtu zadaných parametrů

[Josef Kufner]

Jo, tohle jsem tu psal před pár dny

[pht]

Ale je celkem protivné, že ty dotazy se pak nevejdou na obrazovku

To lze řešit VIEWama.

[Josef Kufner]

Nooo... to si nemyslim. Ono ty selecty jsou takove... na jednu stranu celkem jednoduche, na druhou trosku obsahle a plne joinu, ale nacpat tam view moc nejde...

[Michal Kubeček]

tak pripojujes tu tabulku mnohokrat a to je svinstvo

Proč?

[Přemek Vyhnal]

Jak u tohodle řešit když ty hodnoty nejsou vždy jen čísla?  Aby tam byly sloupečky ciselna_hodnota, textova_hodnota atd s tim ze vyplneny bude vzdy jen jeden mi prijde zvlastni ;)

a navíc mohou být hodnoty v různých jednotkách a musí fungovat vyhledávání (třeba hledat všechno menší než 5cm; ale některé položky to mají zadáno v mm a jiné v cm :) To se udělá další tabulka s jednotkama a s převodama mezi nima a pak do tý tabulky s odkazama na zboží, parametr a hodnotou se přidá ješte odkaz na jednotku.

Co si o tom myslí zkušenější? ;)

A když je vyhledávání prasárna tak jak na to líp? ;)

[Josef Kufner]

Jo, takle jsem to udělal a celkem to funguje. Jednotky prostě převeď na jednotné

[happy barney]

pridať tabuľky:
atribut_text
atribut_cislo
popr atribut_cast (tovar sa skladá z týchto jednotlivých tovarov)

ad jednotky: previesť všetko na hlavnú jednotku, popr pridať stĺpec "unit", ak je to potrebné