DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 13. 10. 2008.   #1
Petar Marić
Python Ambassador
Master
 
Avatar Petar Marić
 
Datum učlanjenja: 06.06.2005
Lokacija: Novi Sad
Poruke: 602
Hvala: 28
27 "Hvala" u 17 poruka
Petar Marić će postati "faca" uskoro
Pošaljite ICQ poruku za Petar Marić
Question Mapiranje vrednosti atributa na kolone ili redove?

U izradi svog Master rada sam naišao na jednu dilemu - da li je pametnije mapirati vrednosti atributa na kolone ili redove u tabeli? Slede primeri mapiranja na značajno pojednostavljenim modelima:

Mapiranje na redove:
upitnik(id, kreirao_korisnik_fk, naziv)
pitanje(id, upitnik_fk, tekst_pitanja, redosled, ...)
ponudjeni_odgovor(id, pitanje_fk, tekst_odgovora, redosled, ...)
korisnikov_odgovor(id, korisnik_fk, pitanje_fk, ponudjeni_odgovor_fk, ...)
Mapiranje na kolone:
upitnik(id, kreirao_korisnik_fk, naziv)
pitanje(id, upitnik_fk, tekst_pitanja, odgovori*, redosled, ...)
korisnikov_odgovor(id, korisnik_fk, upitnik_fk, odgovor1, odgovor2, ..., odgovorN**, ...)
* polje je tekstualnog tipa i u njemu su pojedinačni odgovori međusobno razdvojeni karakterom za novi red.
** odgovorX je odgovor na X-to pitanje upitnika. Takođe se unapred pri projektovanju baze mora postaviti ograničenje na maksimalni mogući broj ponuđenih odgovora na 1 pitanje.

Mapiranjem na kolone se postiže manji broj redova, ali su tada neke kolone NULL. Takođe se unapred mora odrediti maksimalni podržani broj ponuđenih odgovora na 1 pitanje.

Baza za koju sam dao 2 potencijalna modela je primarno namenjena za prihvatanje podataka (OLTP), ali bi bilo lepo kada bi bila prilagođena i za osnovno OLAP korišćenje da bi se izbeglo korišćenje 2 baze i njihova sinhronizacija, bar u početku.

Šta vi mislite?
__________________
Python Ambassador of Serbia
Petar Marić je offline   Odgovorite uz citat
Staro 13. 10. 2008.   #2
Dejan Topalovic
old school
Professional
 
Datum učlanjenja: 15.02.2006
Lokacija: Wien, Austria
Poruke: 304
Hvala: 121
47 "Hvala" u 26 poruka
Dejan Topalovic će postati "faca" uskoro
Pošaljite poruku preko MSN za Dejan Topalovic
Default

Mapiranje na redove - tačka.
__________________
Blog: Baze podataka
------------------------
Oracle OCP DBA
Oracle OCE SQL Expert
Oracle OCP Developer
Certified MySQL DBA
Dejan Topalovic je offline   Odgovorite uz citat
Staro 14. 10. 2008.   #3
pkrstic
profesionalac
Qualified
 
Avatar pkrstic
 
Datum učlanjenja: 06.09.2007
Lokacija: Zrenjanin
Poruke: 109
Hvala: 21
11 "Hvala" u 11 poruka
pkrstic is on a distinguished road
Default

Citat:
Originalno napisao Petar Marić Pogledajte poruku
Kôd:
korisnikov_odgovor(id, korisnik_fk, upitnik_fk, odgovor1, odgovor2, ..., odgovorN**,  ...)
zasto i ove odgovore ne kodiras u string, tako ces moci da imas promenljivu duzinu upitnika, ovde ces imati fiksnu duzinu uvek (ne znam da li ti je to cilj, tj da li je tako i zamisljeno).
pkrstic je offline   Odgovorite uz citat
Staro 18. 10. 2008.   #4
Petar Marić
Python Ambassador
Master
 
Avatar Petar Marić
 
Datum učlanjenja: 06.06.2005
Lokacija: Novi Sad
Poruke: 602
Hvala: 28
27 "Hvala" u 17 poruka
Petar Marić će postati "faca" uskoro
Pošaljite ICQ poruku za Petar Marić
Default

@Dejan: Da li bi mogao da mi obrazložiš svoje mišljenje i/ili da me uputiš na literaturu? Želeo bih da imam pokriće na odbrani.

@pkrstic: Neka od tih polja bi bila NULL tako da upitnik i dalje može biti promenljive dužine. Iz priče sa psiholozima smo došli do zaključka da upitnici treba da imaju konačan broj pitanja (30-ak je maksimum u većini slučajeva) inače dovodi do rasplinjavanja i smaranja ispitanika.

Inače, jedini razlog razmišljanja o mapiranju na kolone je da onda struktura podataka "liči" na OLAP data cube - ne znam da li je takav pristup dobar jer u ovom trenutku nemam praktičnog iskustva.
__________________
Python Ambassador of Serbia
Petar Marić je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
CSS LAYOUT: 4 fiksne kolone? maksim (X)HTML, JavaScript, DHTML, XML, CSS 4 21. 04. 2007. 20:31
Filtriranje nezeljenih atributa u html-u dinke Regular expression i htaccess 10 10. 03. 2007. 23:20
tri kolone, dve kolone :) z.zoran (X)HTML, JavaScript, DHTML, XML, CSS 14 02. 03. 2007. 15:17
CSS - elastične kolone kao tabela Pedja (X)HTML, JavaScript, DHTML, XML, CSS 13 10. 02. 2007. 14:29


Vreme je GMT +2. Trenutno vreme je 21:53.


Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.