filtrovanie obsahu z databazy

cawte poradte mi ako vyhladavate v databaze napriklad mam zariadenie ktore ma v stlpci "tovar" string napriklad 1,2,5,10 (druhy tovaru).

uzivatel zasrktne 2 a 5 checkbox a ja potrebujem spravit query ...ako to robite ?...vytiahnete vsetky a potom si to napriklad hodite do kontrolnych poli a skontrolujete ci sa jedno(ktore pride zo stranky) nachadza v druhom(ktore je v db) alebo priamo v selecte ??...nvm... poradte nejaku moznost

Zlý návrh databázy - druhy tovaru by nemali byť v jednom stĺpci (a k tomu ešte string).

priklad: mas 1 predajnu a chces k nej vlozit aky druh tovaru v nej predavas ... ako to spravis ?...

ja to mam

id_predajna nazov kraj druhy_tovarov
44 obchod u mna 4 1,2,5,6

v inej tabulke mam

id_tovar nazov
1 drogeria
2 potraviny

ako by si to spravil ty ?

Na to slúži napríklad prepojovacia tabuľka.
V nej budeš mať id_predajne a id_tovaru a potom iba vytiahneš všetky id_predajne, ktoré majú priradený id_tovaru.

Napríklad by ma zaujímalo, ako riešiš editáciu? V tom tvojom príklade, ako by si odobral z predajne č. 44 druh tovaru č. 5?

editaciu ?.. otvoris si profil predajne a z formualara zoberies checkboxy druhy-tovaru[] a spojis ich do jedneho stringu .. nic viac (len tie ktore su checked) teda su v poli $_POST ['druhy-tovaru ']

shaggy, dá sa to aj tak, ako to robí DeeJay3, akurát je to prasácke riešenie, ktoré nemá s relačnými datábazami nič spoločné

DJ3, prečo sa nedoučíš dačo o databázach, ich návrhu atď? Ušetríš si do budúcnosti veľa problémov.

uz bez tychto prepojovacih tabuliek mam v databaze 106 tabuliek chcel som len zmensit ich mnozstvo ... o databazach viem da sa povedat 90% .. lenze proste chcel som to riesit takto

106 tabuliek takýmto spôsobom? A to vieš o databázach 90% a pýtaš sa na takéto základné veci "ako by si to riešil ty shaggy?" ???
To ako vážne, hej?

Teraz vážne, ak by si vedel o db toľko, čo vravíš, takéto riešenie by ťa ani napadnúť nemalo.

Čo to je prosím ťa za databáza? Začínam mať tušáka, že celá db bude na

mam 36 tabuliek v ktorych su preklady vynasob si to x2 a vyjde ti pocet tabuliek LEN K DRUHOM ZARIADENI...

hotely (id_hotel, pocet_hviezdiciek ...)
hotely_preklady (id_preklad, id_hotel, jazyk, nazov ...)

chaty (id_hotel, kapacita ...)
chaty_preklady (id_preklad, id_chata, jazyk, nazov ...)

.. .. ..
.. .. ..

spolu to je 72 a to neviem ci som to dobre spocital .. k tomu mam plno dalsich tabuliek ktore potrebujem..prepojenia zariadeni ..a tak dalej a tak dalej...vysvetli mi co je tu na ??

No minimálne z tohto tvojho popisu vidím duplicitu, ktorá je totálne nezmyselná.
Hotely a chaty vyzerajú, že majú rovnaké "vlastnosti". Líšia sa len "typom". Inými slovami, miesto tabuliek "chaty, hotely, ..." by pravdepodobne stačila jediná tabuľka s názvom povedzme "zariadenia".
Ťažko povedať podľa informácií, ktoré si zatiaľ dodal, ale 106 tabuliek je neskutočne premrštené množstvo a by som sa s tebou aj stavil, že zbytočne.

aj by som sa s tebou stavil ze nie ..

povedz mi ake informacie maju spolocne aqupark hotel hrad jaskyna ?..hmmmmmmmmmm ???

To ti mám toto všetko NAOZAJ začať vysvetľovať? hmmmmmmmmm ???
shaggy má pravdu, že ide o zlý návrh databázy a ty ma v tom názore zatiaľ len utvrdzuješ.
Nerozumiem, prečo to musíš za každú cenu takto urputne (a nehnevaj sa, zároveň aj komicky) obhajovať. Koľkí ti tu musíme povedať, že to nerobíš správne?

Aby sme ti tu vedeli konkrétne poradiť, ako tabuľky zoptimalizovať, musel by si to tu všetko vypísať a mám silné pochybnosti, že by sa tu dakomu chcelo refaktorovať 100 tabuliek. Sadni si k tomu v kľude, naštuduj si princípy návrhu databázy, fungovaniu relácií atď, a pozri sa na to znovu. Takto na fóre to nemá zmysel všetko vypisovať, to je učivo na niekoľko kníh.

Je otázne, či je na niečo také najvhodnejšie SQL (keďže tie kategórie sú príliš rozdielne; v podstate aj samotná adresa je na ukladanie do "normálnych" tabuliek príliš zložitá).

Ak ale na serveri musí použiť nejakú SQL databázu, tak sa kopcu tabuliek asi nevyhne a DB server si s nimi bez problémov poradí.

Tie tabuľky s prekladmi sú tam ale, podľa mňa, úplne zbytočné (netuším, prečo tam nestačí jediná taká tabuľka).

pretoze chata ma stlpce: ubytovanie, popis izieb, marketingovy profil, pre_deti, vybavenie,
a jaskyna ma: akcie prostredie okolie druh velkost kvapli ...co to ma spolu spolocne ???...

ma jaskyna vybavenie alebo popis kuchyne ?...tak mi to niekto vysvetlite ako inak to mam spravit ..co mam spravit jednu maximalne obrovsku tabulku v ktorej bude milion zaznamov a po **** (velmi vela) prazdnych buniek ??

// pridané po 2 minútach od posledného príspevku

a ABSOLUTNE NECHAPEM AKO SOM TA V TOM UTVRDIL ZREJME NECITAS CO SOM TI HNED ZA TYM NAPISAL ZE MAJU UPLNE ODLISNE STLPCE TIE TABULKY ...TAK SI SKUS TAKU TABULKU NAVRHNUT TY V 5 JAZYKOVYCH VARIACIACH 20 DRUHOM ZARIADENI A VSETKO V JEDNOM ..SOM ZVEDAVY CO NA TO POTOM POVIES POTOM

porovnávaš vkuse jaskyňu s hotelom. FAJN, to sú dve tabuľky. To ale nevysvetľuje ďalších 105. Ako písal chrono, tabuľky s prekladom sú takisto zbytočnosť. To už zráža počet tabuliek takmer na polovicu atď.

ad1: capslock? Naozaj? Nestačí, že tu nezmyselne obhajuješ zlý databázový návrh, ešte sa budeš aj rozkrikovať ?
ad2: ako súvisí táto téma s php/asp?

a co ine ti mam porovnat aby si pochopil ze tie zariadenia maju MINIMUM spolocneho ?...chatu z hotelom?..spokojnost?..uuu o 1 tabulku menej ..tak to som rad .. a kde das preklady KED ANI V NICH NEMAJU JENDNOTLIVE ZARIADENIA ROVNAKE INFORMACIE ? nebudem sa uz k tebe vyjadrovat lebo stale trepes to iste dookola a nic si este nevymyslel...stale len dookola dat to dokopy pomazat to zredukovat .. uz sa k tejto teme radsej nevyjadruj ak nevies uviest priklad ako ..

Ako ti mám uviesť príklad "ako", keď nikde nevidím podrobný rozpis toho, čo treba zrealizovať? Ty vieš vyrobiť databázový návrh z viet "jaskyňa, chata, hotel.. čo majú spoločné ha??!" Zredukovať počet si môžeš len sám a aj to až po tom, ako sa to naučíš robiť poriadne a zbavíš sa toho prístupu "hej, došiel som si sem po radu, ale ja to viem aj tak najlepšie!!!!!"

Ale pre mňa za mňa sa postav aj na hlavu, mám omnoho lepšiu robotu jak tu riešiť tvoje tabuľky. Človek príde poradiť, ale komu niet rady, tomu niet pomoci. A kľudne sa aj hoď o zem.

chcel som vediet ako to filtrovat ked to mam takto navrhnute ...spravit tu prepojovaciu tabulku mi nerobi problem...ale redukovat tabulky absolutne nema zmysel pretoze mat vsetko pokope je nezmysel pretoze tam bude neskutocny pocet prazdnych buniek

// pridané po 7 hodinách 51 minútach od posledného príspevku

a teraz ked chcem do tej prepojovacej vkladat z formulara ktore druhy tam maju byt ?... ako to spravit ?..a ako updatnut udaje v tabulke pre dane zariadenie ?...

teraz tam mas napriklad:

id_prepojenie id_zariadenie druh_zariadenia druh_tovaru
1 4 2 4
2 4 2 5
3 3 1 4

ako spravit insert a update ? .. napriklad na pouzitie druh-tovaru[] ako pola ktore mi pride z formulara 1,4,5 napriklad

keby islo len o znizenie poctu tabuliek tak vsetky tabulky by mohol narvat do jedinej
ktora by mala stlpce "TABLE_NAME", "ROWNUMBER", "COLUMN_NAME","COLUMN_VALUE". do takejto jednej tabulky by natlacil obsah celej db )))))))))))

V prvom rade by si mohol uviest, ake konkretne udaje potrebujes v db uchovavat, z toho sa daju potom urcit najvhodnejsie varianty struktury tabuliek, ktore mozes nasledne zredukovat po zohladneni roznych priorit (prevladajuce operacie, vykon, ...)

chaty:

id_chata, datum_registracie, kategoria, rating, vzdialenosti (bus, vlak, skibus, vlek, zjazdovka, bezecka trasa, cyklisticka trasa, turisticka trasa, les, jazero, bazen, aquapark), vzdialenosti_od_miest, polohy, adresa_nazov, adresa_ulica_cd, obec_mesto, kraj, okres, adresa_psc, turisticky_region, telefon, email, web, ico, dic, ic_dph, bankove_spojenie, cislo_uctu, iban, swift, komunikacne_jazyky, sposoby_platby, vybavenie, stravovanie, vybavenie_pre_deti, gps_n, gps_e, kontaktna_osoba, google_mapa, status, kapacita

chaty preklady:

id_preklad chata_id jazyk nazov letne_aktivity zimne_aktivity marketingovy_popis opis_zariadenia opis_okolia atrakcie pristup komunikacne_jazyky

hrady:

id_hrad, typ, mesto, okres, kraj, adresa, telefon, fax, email, web, 1_sezona_datum, 2_sezona_datum, 3_sezona_datum, 4_sezona_datum, dospely, student, deti1Vek, deti1Cena, deti2Vek, deti2Cena, mapa, zdroj, foto_autor, gps_n, gps_e, status, poznMeno, poznKontakt, poznText

hrady preklady:

IDpreklad IDhrad jazyk nazov spravca expozicie_vizitka marketing_popis_short marketing_popis_long 1_sezona_cas 2_sezona_cas 3_sezona_cas 4_sezona_cas about okolie historia muzeum pristup cennikPopis otvaracieHodinyPopis

...
... a tak dalej

v zakladnej tabulke retazec(1,2,4-toto asi prerobit cez prepojovaciu napriklad: vzdialenosti), varchar ,int, text
v prekladoch vsetko text alebo varchar

Skôr je dôležité, s akými údajmi potrebuje pracovať (vyhľadávať, zoraďovať...). Tie údaje, čo sa majú iba zobrazovať, môžu byť pokojne serializované v blobe a ničomu to nebude vadiť.



Čo som si všimol, tak vo viacerých tabuľkách máš stĺpce s polohou toho zariadenia. Na to by stačila bez problémov jediná tabuľka s polohou, v ktorej by bola uložená poloha pri všetkom, pri čom to má zmysel (v takom prípade by to ale chcelo tabuľku, v ktorej by bol jedinečný identifikátor pre každé zariadenie).

Čo som si ďalej všimol je to, že v tabuľke hrady sú stĺpce {1,2,3,4}_sezona_cas. Netuším, na čo to slúži, ale je zrejmé, že ide o nie príliš dobrý návrh (pretože, čo ak bude potrebný aj 5 čas, alebo niekde bude na všetko stačiť len jedna položka).
Rovnaký problém je pri ďalších údajoch (napr. tarify) a niekdy by mohlo byť vhodné mať viac údajov rovnakého typu (adresa, kontakt, mapa...) a pri súčasnom návrhu DB by s tým bol problém.

Verím, že preklady sa budú dať dostať do jedinej tabuľky, takže kopec tabuliek by odtiaľ zmizol aj kvôli tomu by to chcelo nejakú cache, aby sa takéto údaje nemuseli neustále načítavať z DB (budú viac-menej statické).

Inak ak potrebuješ pracovať s free-form údajmi, tak SQL nemusí byť najlepšie riešenie.

PS: Správne spracovávanie takto rôznorodých údajov je naozaj komplikované a treba sa nad tým naozaj dobre zamyslieť, pretože neustále meniť štruktúry tabuliek nemusí byť to najlepšie.
PPS: Tohoto problému sa čiastočne týka aj zaujímavý článok Personal names around the world.

no s tou polohou je to dobry napad .. tiez adresy a podobne ..lenze na to nemusim mat podla mna dalsiu tabulku spolocnu ked to mam osobitne v jednotlivych podla typu (hotely, chaty, ...)

preklady: no ja neviem .. bude to obrovska tabulka s vela prazdnymi miestami .. pre kazde zariadenie

stranku budem prerabat takze kazda zmena ktora bude viest k dobru mi pomoze

ine ako SQL databazy a tabulky na ukladanie udajov nepouzivam .. mozno ani nic ine nepoznam .. :/

Nemusíš mať ďalšiu tabuľku, môžeš mať v tej tabuľke s adresami typ tabuľky (napr. hotely) a id v tej tabuľke hotely. Urobíš tam index cez oba stĺpce a s rýchlosťou vyhľadávania by nemal byť príliš veľký problém. Je ale možné, že ak by si do tej spoločnej tabuľky dal spoločné údaje, tak by to mohlo byť rýchlejšie (hlavne, ak by tam boli dôležité veci, pomocou ktorých sa údaje často vyhľadávajú, triedia).

Prečo by malo byť v tej tabuľke s prekladmi veľa miesta? Budeš tam mať identifikator toho zariadenia (či už ako jedno id, alebo ako dve, rovnako ako v predchádzajúcom prípade), stĺpec, v ktorom bude niečo, podľa čoho budeš vedieť, ktorý reťazec pre to zariadenie vlastne prekladáš, jazyk, samotný text... (čiže údaje, ktoré budú vždy vyplnené kompletne).

Kde si bol, keď si nikde nenarazil na "hnutie" NoSQL? Napr. v MongoDB, CouchDB... ukladáš údaje v JSON/BSON tvare, a je úplne jedno, aký majú tvar (samozrejme potom musíš vyriešiť v aplikácii, čo sa bude zobrazovať a ako a celé to môže, ale aj nemusí byť jednoduchšie).