| Autor | Správa |
|---|
DeeJay3
Užívateľ
Založený: 28.02.2009
Príspevky: 196
 |
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 .. |
| |
  |
|
walther
Užívateľ
Založený: 24.01.2008
Príspevky: 10194
Bydlisko: Bratislava
Vek: 24
|
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. |
| |
|
|
DeeJay3
Užívateľ
Založený: 28.02.2009
Príspevky: 196
|
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 |
| |
|
|
coldak
Skúsený užívateľ
Založený: 29.10.2008
Príspevky: 936
|  Zaslal: Št 10.11.11 11:07 |   |
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  ))))))))))) |
| |
|
|
stenley
Moderátor
Založený: 27.07.2007
Príspevky: 3776
Bydlisko: Bratislava
Vek: 27
| | Zaslal: Št 10.11.11 12:58 | |
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, ...) |
_________________
Desktop: CPU: AMD Athlon64 3000+ | MB: Biostar K8T890-A9 | VGA: NVIDIA GeForce 6200 LE 256MB | RAM: 2x 1GB A-DATA DDR 400 MHz Dual Kit | HDD: WD Caviar Blue 320GB | DVD: LG GSA-H10N | Keyboard: Chicony KU-0420 Silver/Black | Mouse: Logitech RX1000 | Zdroj: Corsair CX400 400W | CASE: DELUX DLC-MD370 Black | LCD: 20" Samsung 206BW | Repro: Teac XL-20
Notebook: ACER Aspire 4820TG 14" | CPU: Intel Core i5 2,53 GHz | VGA: ATI Mobility Radeon HD5650 1GB / Intel HD Graphics | RAM: 4GB DDR3 1066 MHz | HDD: 640GB | |
  |
|
DeeJay3
Užívateľ
Založený: 28.02.2009
Príspevky: 196
| | Zaslal: Št 10.11.11 13:25 | |
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 |
| |
|
|
chrono
Skúsený užívateľ
Založený: 13.11.2007
Príspevky: 808
| | Zaslal: Št 10.11.11 15:56 | |
| stenley napísal: | | 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, ...) |
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. |
| |
|
|
DeeJay3
Užívateľ
Založený: 28.02.2009
Príspevky: 196
| | Zaslal: Št 10.11.11 16:28 | |
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 .. :/ |
| |
|
|
chrono
Skúsený užívateľ
Založený: 13.11.2007
Príspevky: 808
| | Zaslal: Št 10.11.11 16:47 | |
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). |
| |
|
|
|
Nemôžete pridávať nové témy do tohto fóra.
Nemôžete odpovedať na témy v tomto fóre.
Nemôžete upravovať svoje príspevky v tomto fóre.
Nemôžete mazať svoje príspevky v tomto fóre.
Nemôžete hlasovať v tomto fóre.
|
|
