usuwanie =?ISO-8859-2?Q?rekord=F3w?=
zbig - 08-08-2007 00:02
usuwanie =?ISO-8859-2?Q?rekord=F3w?=
Witajcie,
Mam ogólny problem natury projektowej. Najlepiej będzie to wyjaśnić na
przykładzie. Załóżmy, że mamy takie tabele:
CREATE TABLE osoba (
id int UNIQUE,
nazwa text UNIQUE,
opis text,
PRIMARY KEY(id)
);
CREATE TABLE usluga (
id int UNIQUE,
nazwa text UNIQUE,
opis text,
PRIMARY KEY(id)
);
CREATE TABLE logi (
id int UNIQUE,
osobaid int REFERENCES osoba,
uslugaid int REFERENCES usluga,
opis text,
PRIMARY KEY(id)
);
i teraz załóżmy że z tabeli logi nie można usuwać, w związku z tym nie można
też usuwać osób i usług. Aby można było temu zapobiec używam do tabel
osoba/usluga dodatkowej kolumny "deleted boolean" przez to na poziomie bazy
relacja zawsze istnieje a już w warstwie widoku pilnuję żeby nie wypisywał
elementów które są deleted. Ma to jednak swoje małe minusy np. kolumny
nazwa nie mogą być wtedy jako UNIQUE bo ktoś mógł dodać-usunąć-dodać tą
samą nazwę i ona musi występować kilka razy i jest też podobnych niuansów
jeszcze trochę.
Pytanie brzmi jak Wy rozwiązujecie podobne problemy, też dodajecie
kolumnę "deleted", czy może inaczej? Używałem jeszcze czasami opcji że w
tabeli logi zamiast osobaid i uslugaid wpisywałem ich nazwy i wtedy można
usuwać dane osoby i usługi ale często są sytuacje, że potrzebne mi są
wszystkie właściwości tych usuniętych obiektów.
--
Pozdrawiam,
zbig
A.L.E.C - 08-08-2007 00:02
zbig wrote:
> Pytanie brzmi jak Wy rozwiązujecie podobne problemy, też dodajecie
> kolumnę "deleted", czy może inaczej? Używałem jeszcze czasami opcji że w
> tabeli logi zamiast osobaid i uslugaid wpisywałem ich nazwy i wtedy można
> usuwać dane osoby i usługi ale często są sytuacje, że potrzebne mi są
> wszystkie właściwości tych usuniętych obiektów.
np. tak:
http://www.depesz.com/index.php/2006...-uzytkownikow/
--
Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252
LAN Management System Developer http://lms.org.pl
Marcin - 08-08-2007 00:03
zbig wrote:
> Witajcie,
>
> Mam ogólny problem natury projektowej. Najlepiej będzie to wyjaśnić na
> przykładzie. Załóżmy, że mamy takie tabele:
> CREATE TABLE osoba (
> id int UNIQUE,
> nazwa text UNIQUE,
> opis text,
> PRIMARY KEY(id)
> );
> CREATE TABLE usluga (
> id int UNIQUE,
> nazwa text UNIQUE,
> opis text,
> PRIMARY KEY(id)
> );
> CREATE TABLE logi (
> id int UNIQUE,
> osobaid int REFERENCES osoba,
> uslugaid int REFERENCES usluga,
> opis text,
> PRIMARY KEY(id)
> );
>
> i teraz załóżmy że z tabeli logi nie można usuwać, w związku z tym nie można
> też usuwać osób i usług. Aby można było temu zapobiec używam do tabel
> osoba/usluga dodatkowej kolumny "deleted boolean" przez to na poziomie bazy
> relacja zawsze istnieje a już w warstwie widoku pilnuję żeby nie wypisywał
> elementów które są deleted. Ma to jednak swoje małe minusy np. kolumny
> nazwa nie mogą być wtedy jako UNIQUE bo ktoś mógł dodać-usunąć-dodać tą
> samą nazwę i ona musi występować kilka razy i jest też podobnych niuansów
> jeszcze trochę.
> Pytanie brzmi jak Wy rozwiązujecie podobne problemy, też dodajecie
> kolumnę "deleted", czy może inaczej? Używałem jeszcze czasami opcji że w
> tabeli logi zamiast osobaid i uslugaid wpisywałem ich nazwy i wtedy można
> usuwać dane osoby i usługi ale często są sytuacje, że potrzebne mi są
> wszystkie właściwości tych usuniętych obiektów.
Ograniczenia typu UNIQUE, FOREIGN KEY mają Ci ułatwiać życie,
a nie utrudniać. Jeśli są niewygodne, to ich nie używaj.
Przykładowo: jeśli masz problem z UNIQUE, bo mogą być w tabeli
wpisy "deleted" i nie ma powodu, żeby dwie nazwy nie mogły
się powtórzyć, to nie stosuj UNIQUE, tylko napisz triggera,
który przed wstawieniem/zmianą rekordu sprawdzi, czy nie ma
powtarzającej się nazwy wśród rekordów "not deleted".
M.
zbig - 08-08-2007 00:03
Marcin wrote:
> Ograniczenia typu UNIQUE, FOREIGN KEY mają Ci ułatwiać życie,
> a nie utrudniać.
Słuszna uwaga, dzięki
zbig
hubert depesz lubaczewski - 08-08-2007 00:03
Dnia 07.08.2007 Marcin <spam@noaddress.xx> napisał/a:
> się powtórzyć, to nie stosuj UNIQUE, tylko napisz triggera,
> który przed wstawieniem/zmianą rekordu sprawdzi, czy nie ma
> powtarzającej się nazwy wśród rekordów "not deleted".
ekhem. i wstaw sobie w kod race condition? "świetny" pomysł.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
hubert depesz lubaczewski - 08-08-2007 00:03
Dnia 07.08.2007 zbig <zbigrun@gmail.com> napisał/a:
> i teraz załóżmy że z tabeli logi nie można usuwać, w związku z tym nie można
> też usuwać osób i usług. Aby można było temu zapobiec używam do tabel
> osoba/usluga dodatkowej kolumny "deleted boolean" przez to na poziomie bazy
> relacja zawsze istnieje a już w warstwie widoku pilnuję żeby nie wypisywał
> elementów które są deleted. Ma to jednak swoje małe minusy np. kolumny
> nazwa nie mogą być wtedy jako UNIQUE bo ktoś mógł dodać-usunąć-dodać tą
> samą nazwę i ona musi występować kilka razy i jest też podobnych niuansów
> jeszcze trochę.
1. o unique już ci napisano.
2. w/g mnie tabela logi nie powinna mieć żadnych kluczy obcych, ani
wartości _id. tylko wartości już tekstowe. czyli username czy coś
takiego.
jeśli z jakiegoś powodu potrzebujesz też id - fajnie. dodaj, ale nie rób
na nim fkeya.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
zbig - 08-08-2007 00:03
hubert depesz lubaczewski wrote:
> 2. w/g mnie tabela logi nie powinna mieć żadnych kluczy obcych, ani
> wartości _id. tylko wartości już tekstowe. czyli username czy coś
> takiego.
> jeśli z jakiegoś powodu potrzebujesz też id - fajnie. dodaj, ale nie rób
> na nim fkeya.
To był tylko przykład, te tabele istnieją tylko w tym wątku :)
A co do unikalności to Twój wpis w blogu już rozwiązał problem, dzięki
zbig
Marcin - 08-08-2007 00:03
hubert depesz lubaczewski wrote:
> Dnia 07.08.2007 Marcin <spam@noaddress.xx> napisał/a:
>> się powtórzyć, to nie stosuj UNIQUE, tylko napisz triggera,
>> który przed wstawieniem/zmianą rekordu sprawdzi, czy nie ma
>> powtarzającej się nazwy wśród rekordów "not deleted".
>
> ekhem. i wstaw sobie w kod race condition? "świetny" pomysł.
Nie za bardzo rozumiem. Chodzi o izolację transakcji?
Mogę sobie ustawić odpowiednią do tego celu.
M.
hubert depesz lubaczewski - 08-08-2007 00:03
Dnia 07.08.2007 Marcin <spam@noaddress.xx> napisał/a:
>>> się powtórzyć, to nie stosuj UNIQUE, tylko napisz triggera,
>>> który przed wstawieniem/zmianą rekordu sprawdzi, czy nie ma
>>> powtarzającej się nazwy wśród rekordów "not deleted".
>> ekhem. i wstaw sobie w kod race condition? "świetny" pomysł.
> Nie za bardzo rozumiem. Chodzi o izolację transakcji?
> Mogę sobie ustawić odpowiednią do tego celu.
ekhem. i robić od razu serializację do tak prostej rzeczy? to trochę
zarzyna wydajność.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Wydajność baz danych w zależności od poziomu izolacji ANSI/ISO
Czy zna (obsługuje) ktoś program Iso Draw ?
MYSQL - kodowanie w ISO-PL
strona plus baza w iso do utf-8
Kodowanie: z iso na utf
Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
=?iso-8859-2?q?Co_oznacza_b=B3=B1d_Warning:_mysql=5Fconnect() _[function.mysql-connect]:_Can't_connect_to_local_MySQL_server_through_sock et_'/var/run/mysqld/mysqld.sock'_(2)_in?=
=?iso-8859-2?q?Informatyka,_Java,_EJB,_Ajax,_Spring=2E_Czy=BF by_to_koniec_=B6wiata,_czy_te=BF_nasze_uczelnie_b= EAd=B1_uczy=B3y_w_ko=F1cu!_czego_praktycznego_=2E= 2E=2E=2E?=
=?iso-8859-2?q?Ati_Mobility_Radeon_X300_W_Notebooku_Jak_Zwi=E Akszy=E6_Ilo=B6=E6_Grafiki_Poprzez_Wsp=F3=B3dziele nie_Z_Ramu=3F=3F=3F?=
=?ISO-8859-2?Q?=AFegnam_si=EA=2E=2E=2E?=
zanotowane.pldoc.pisz.plpdf.pisz.plfantazia.htw.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 |
|
