Projektowanie prostej bazy
MacFly - 14-11-2006 00:09
Projektowanie prostej bazy
Witam,
Planuje stworzyć małą bazę danych na potrzeby strony WWW i mam kilka
wątpliwości z tym związanych.
Uproszczę problem to trzech tabel.
Mamy użytkownika, który może wstawiać komentarze, a komentarze i użytkownicy
maja dodatkowo kilka informacji wspólnych jak np. data dodania itd.
Przychodzi mi do głowy takie rozwiązanie, ale wydaje się być mało efektywne:
Users (PK) --------------------------- (FK) Comments
| (FK) |(FK)
I I
I I
I (PK) I(PK)
PolaWspólneDlaObuTabel
(INFO)
Tabela INFO będzie rosnąć strasznie szybko, jak będę chciał znaleźć date
wygaśnięcia konta użytkownika to będę musiał przejrzeć wszystkie daty
komentarzy ;/
Pond to, będą jeszcze inne tabele jak np. Newsy, które będą w relacji z
tabelami info i users. Tworzy się straszna pajęczyna
Nie mam wielkiego doświadczenia w tworzeniu baz danych, dlatego będę
wdzięczny za każdą pomoc.
Michał Kuratczyk - 14-11-2006 00:09
MacFly wrote:
>
> Users (PK) --------------------------- (FK) Comments
>
> | (FK) |(FK)
>
> I I
>
> I I
>
> I (PK) I(PK)
>
> PolaWspólneDlaObuTabel
>
> (INFO)
Dlaczego każdy na tej grupie próbuje wymyślić własną notację dla tabel
i relacji? SQL nie działa już? Nie można gotowych CREATE TABLE podać?
Ja z tego rysunku niewiele rozumiem, a co gorsza Ty możesz zapisywać błędne
rzeczy w takiej postaci, że my odczytamy to dobrze (bo założymy, że miałeś
na myśli to co powinieneś mieć, a nie to co faktycznie miałeś). Ufff. :->
> Tabela INFO będzie rosnąć strasznie szybko,
Po to są bazy danych, żeby do nich dane zapisywać.
> jak będę chciał znaleźć date wygaśnięcia konta użytkownika to będę musiał
> przejrzeć wszystkie daty komentarzy ;/
Dlaczego?
> Pond to, będą jeszcze inne tabele jak np. Newsy, które będą w relacji z
> tabelami info i users. Tworzy się straszna pajęczyna
Pajęczyna? Kilka tabel i już pajęczyna? Na tym po prostu polegają relacyjne
bazy danych. Aplikacja mająca kilkaset tabel nie jest niczym niezwykłym.
--
Michał Kuratczyk
MacFly - 14-11-2006 00:09
Przepraszam, to mój pierwszy post na tym forum :)
SQL:
Create table [users]
(
[idUser] Integer NOT NULL, UNIQUE ([idUser]),
[name] Char(50) NULL,
[surename] Char(50) NULL,
[idInfo] Integer NOT NULL,
Primary Key ([idUser])
)
Create table [comment]
(
[idComment] Integer NOT NULL, UNIQUE ([idComment]),
[idUser] Integer NOT NULL,
[idInfo] Integer NOT NULL,
[text] Text NULL,
Primary Key ([idComment])
)
Create table [info]
(
[idInfo] Integer NOT NULL, UNIQUE ([idInfo]),
[activated] Datetime NULL,
Primary Key ([idInfo])
)
Alter table [comment] add foreign key([idUser]) references [users]
([idUser]) on update no action on delete cascade
Alter table [comment] add foreign key([idInfo]) references [info]
([idInfo]) on update no action on delete cascade
Alter table [users] add foreign key([idInfo]) references [info] ([idInfo])
on update no action on delete cascade
Użytkownik "Michał Kuratczyk" <kura@lj.pl> napisał w wiadomości
news:eishth$2im8$1@news2.ipartners.pl...
> MacFly wrote:
>>
>> Users (PK) --------------------------- (FK) Comments
>>
>> | (FK) |(FK)
>>
>> I I
>>
>> I I
>>
>> I (PK) I(PK)
>>
>> PolaWspólneDlaObuTabel
>>
>> (INFO)
> Dlaczego każdy na tej grupie próbuje wymyślić własną notację dla tabel
> i relacji? SQL nie działa już? Nie można gotowych CREATE TABLE podać?
> Ja z tego rysunku niewiele rozumiem, a co gorsza Ty możesz zapisywać
> błędne
> rzeczy w takiej postaci, że my odczytamy to dobrze (bo założymy, że miałeś
> na myśli to co powinieneś mieć, a nie to co faktycznie miałeś). Ufff. :->
>
>> Tabela INFO będzie rosnąć strasznie szybko,
> Po to są bazy danych, żeby do nich dane zapisywać.
>
>> jak będę chciał znaleźć date wygaśnięcia konta użytkownika to będę musiał
>> przejrzeć wszystkie daty komentarzy ;/
> Dlaczego?
>
>> Pond to, będą jeszcze inne tabele jak np. Newsy, które będą w relacji z
>> tabelami info i users. Tworzy się straszna pajęczyna
> Pajęczyna? Kilka tabel i już pajęczyna? Na tym po prostu polegają
> relacyjne
> bazy danych. Aplikacja mająca kilkaset tabel nie jest niczym niezwykłym.
>
> --
> Michał Kuratczyk
Michał Kuratczyk - 14-11-2006 00:09
MacFly wrote:
> Create table [info]
> (
> [idInfo] Integer NOT NULL, UNIQUE ([idInfo]),
> [activated] Datetime NULL,
> Primary Key ([idInfo])
> )
Nadal nie rozumiem po co Ci ta tabela. activated, to jak rozumiem cecha
usera. Czemu nie jest więc tam, gdzie być powinna, czyli w opisie usera?
Jeśli po to, żeby wyświetlać na forum "przyłączył się ...", to przecież
równie dobrze (a właściwie lepiej) możesz to wyczytać z tabeli users.
Co chciałeś osiągnąć tą tabelą?
--
Michał Kuratczyk
Grzesiek G. - 14-11-2006 00:09
MacFly napisał(a):
> Witam,
>
>
>
> Planuje stworzyć małą bazę danych na potrzeby strony WWW i mam kilka
> wątpliwości z tym związanych.
>
>
>
> Uproszczę problem to trzech tabel.
>
> Mamy użytkownika, który może wstawiać komentarze, a komentarze i użytkownicy
> maja dodatkowo kilka informacji wspólnych jak np. data dodania itd.
>
>
>
> Przychodzi mi do głowy takie rozwiązanie, ale wydaje się być mało efektywne:
>
>
>
> Users (PK) --------------------------- (FK) Comments
>
> | (FK) |(FK)
>
> I I
>
> I I
>
> I (PK) I(PK)
>
> PolaWspólneDlaObuTabel
>
> (INFO)
>
>
>
> Tabela INFO będzie rosnąć strasznie szybko, jak będę chciał znaleźć date
> wygaśnięcia konta użytkownika to będę musiał przejrzeć wszystkie daty
> komentarzy ;/
Data wprowadzenia użytkownika nie ma nic wspólnego z datą wprowadzenia
komentarza. Zatem tabele Users i Comments powinny mieć to pole. Jeżeli
komentarz nie może być grupowy to powinien mieć klucz obcy do
użytkownika. Jeżeli relacja między użytkownikami a komentarzami jest
wiele-do-wielu to musi być tabela łącząca. To, że będzie rosła szybko
nie powinno być problemem - wszak celem jest realizacja wymagań
użytkownika, a nie unikanie szybko rosnących tabel. Do rozwiązywania
problemów wydajnościowych służą m.in. indeksy.
A jeżeli chcesz zachować zależność, że na raz wprowadzono i użytkownika
i komentarz to wprowadź do systemu kolejną encję - transakcję. Wtedy
użytkownik i komentarz powinny posiadać klucze obce do transakcji, a
transakcja będzie posiadać atrybut data wprowadzenia.
Pozdrawiam
--
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!
MacFly - 14-11-2006 00:09
Tabela info zawiera jeszcze inne pola, których ze wzgledu na lepszą
czytelność nie umiescilem, a sa wspólne dla wszystkich obiektow nie tylko
dla usera (dla komentarzy, newsow, itd) np. data wygasniecia, dodania,
usuniecia itd.
Sugerujesz wiec, ze lepiej będzie dodać te pola do każdej z tabel z osobna?
Użytkownik "Michał Kuratczyk" <kura@lj.pl> napisał w wiadomości
news:eiskkf$2kdh$1@news2.ipartners.pl...
> MacFly wrote:
>> Create table [info]
>> (
>> [idInfo] Integer NOT NULL, UNIQUE ([idInfo]),
>> [activated] Datetime NULL,
>> Primary Key ([idInfo])
>> )
> Nadal nie rozumiem po co Ci ta tabela. activated, to jak rozumiem cecha
> usera. Czemu nie jest więc tam, gdzie być powinna, czyli w opisie usera?
> Jeśli po to, żeby wyświetlać na forum "przyłączył się ...", to przecież
> równie dobrze (a właściwie lepiej) możesz to wyczytać z tabeli users.
> Co chciałeś osiągnąć tą tabelą?
>
> --
> Michał Kuratczyk
Michał Kuratczyk - 14-11-2006 00:09
MacFly wrote:
> Tabela info zawiera jeszcze inne pola, których ze wzgledu na lepszą
> czytelność nie umiescilem, a sa wspólne dla wszystkich obiektow nie tylko
> dla usera (dla komentarzy, newsow, itd) np. data wygasniecia, dodania,
> usuniecia itd.
>
> Sugerujesz wiec, ze lepiej będzie dodać te pola do każdej z tabel z
> osobna?
Nie sugeruję. Stwierdzam. :->
Myśl o tym w ten sposób - każda tabela, to zbiór pewnych bytów. Każda
kolumna opisuje jakoś ten byt, a każdy wiersz to element tego zbioru.
Użytkownik jest pewnym bytem - jego cechami są między innymi imię
oraz data założenia mu konta. Zatem takie kolumny powinny znaleźć się
w tabeli users.
Oczywiście z czasem sprawa się komplikuje, bo niektóre byty są dość
naciągane (sztuczne) są różne tabele pomocnicze, które trudno jakoś
jednoznacznie sklasyfikować, itd. Ale tym się na razie nie martw.
--
Michał Kuratczyk
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
=?iso-8859-2?Q?=5BMySQL=5D_Wy=B6wietlenie_wszystkich_rekordow _zawierajacy?==?iso-8859-2?Q?ch_duplikat_a__moze_inna_struktura_bazy_danych ?=
Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
=?iso-8859-2?Q?=5BSQL_Server_2000=5D_uprawnienienia_do_u=BFyw ania_widoku_?==?iso-8859-2?Q?opartego_na_tabeli_z_innej_bazy?=
Dwie bazy czy dwie tabele?
[PHP i MySQL] Wstawianie =?ISO-8859-2?Q?rekord=F3w_do_bazy_?==?ISO-8859-2?Q?a_z=B3e_kodowanie?=
=?ISO-8859-2?Q?=5Bmysql=5D_synchronizacja_struktury_bazy_?==? ISO-8859-2?Q?lokalnej_ze_zdaln=B1?=
[Oracle] Co do tworzenia aplikacji dla bazy Oracle
narzedzie do transferu bazy mysql - mysql
narzedzie do transferu bazy odbc - odbc
Połączenie bazy danych z wykonaniem polaczenia telefonicznego
zanotowane.pldoc.pisz.plpdf.pisz.plnawschodzie.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
