1

Temat: Kolumna, która jest potęgą dwójki

Witam,

Coraz częściej zdarza mi się używać operacji na bitach przy ustalaniu, że jeden rekord jest powiązany z kilkoma (1-n).

Np. mamy tabele :

typ_kontaktu - np. dostawca, odbiorca, pośrednik
kontakty - wiadomo

No i teraz 1 kontakt może być jednocześnie np. dostawcą, odbiorcą, no i tutaj można stworzyć kolejną tabelę, która zawierałaby id_typu_kontaktu oraz id_kontakty. Jednak wydaje mi się to zupełnie nie potrzebne w tym przypadku ponieważ typy kontaktu nie będą edytowalne, a także ich liczba jest bardzo mała. Dlatego tutaj postanowiłem zastosować bity. Czyli

typ_kontakt ( id, nazwa, bit )
- 1, dostawca, 1
- 2, odbiorca, 2
- 3, pośrednik, 4

w tabeli kontakty ( id, nazwa, bity )
- 1, firma x, 3 [ czyli jest jednocześnie dostawcą i odbiorcą )
- 2, firma y, 5 [ czyli jest jednocześnie dostawcą i pośrednikiem )

Moje pytanie jest następujące czy w takim przypadku nie byłoby warto ustawić, że bit jest kluczem głównym? Zamiast dodawać dodatkową kolumnę z id, która nigdzie w sumie nie jest używana?

Drugie pytanie czy ktoś wie w jaki sposób zbudować CHECK, aby sprawdzał czy wprowadzona wartość jest potęgą dwójki? Szukałem trochę w polskim google i niestety nie znalazłem.

2

Odp: Kolumna, która jest potęgą dwójki

nie prosciej sobie zrobic tabele wartosci zamiast wartosci bitowej?

3

Odp: Kolumna, która jest potęgą dwójki

W jakim znaczeniu prościej? Jak pisałem rozwiązanie na bitach wyeliminuje jedną tabelę.

SELECT * FROM kontakty WHERE bity & 2 = 2;

W ten sposób znajduję np. odbiorcę. Nie muszę robić żadnych JOIN.

4

Odp: Kolumna, która jest potęgą dwójki

tabelę w sensie array, jako typ kolumny

Ostatnio edytowany przez rski (2008-12-22 18:48:20)

5

Odp: Kolumna, która jest potęgą dwójki

Bity bitami, czasami się przydają smile

Ale to relacyjna baza danych. Wiec relacja wiele do wielu będzie tu chyba rozwiązaniem.
Nie boli ją mała tabelka z wartościami, która będzie opisywać kontakty. (oczywiście + tabela pośrednia jak to bywa w relacji N:M - ale to też same inty)

A co w przypadku jak będziesz chciał usunąć jeden typ ? Będziesz robił updata na całej tabeli, która (przypuszczam) nie będzie mała.
Pytanie: Co potem będzie Ci lepiej utrzymywać
a) bity
- ciężko sprawdzać spójność danych
- kosztowniejsze operacje aktualizacji na tabeli
b) słownik
- opisy w słowniku
- łatwiej o spójność danych
- łatwiej o utrzymanie tabeli
- brak modyfikacji typów (atrybutów) na tabeli opisywanej.

Jak myślicie ? smile

Pozdrawiam
Pawel Socha

6

Odp: Kolumna, która jest potęgą dwójki

@rski: rzeczywiście jest to jakiś pomysł, ale bardziej przydatny przy jakieś większej liczbie danych bo operacje na bitach są prostsze niż te nowe (jak dla mnie) operacje na tablicach

@psocha: masz rację, że tracimy na spójności, ale w niektórych przypadkach to się naprawdę przydaje, bo robić tabelę do każdej pierdoły wydaje mi się zbędne, warto poszukać czasem innego rozwiązania, integralność jest fajna, ale czasem lepiej z niej zrezygnować, ważne tylko by rozumieć ile to nas może kosztować

martwi mnie tylko to, że nie dostałem odpowiedzi na swoje dwa pytania, głównie to dotyczące klucza głównego, bo drugie pytanie na jakimś forum o programowaniu można zadać

Ostatnio edytowany przez stormfly (2009-01-03 15:06:26)

7

Odp: Kolumna, która jest potęgą dwójki

Wydaje sie check na tabeli bylby prostszy niz na bitach wink.
Jesli bit jest unikalny to moze byc kluczem nie wiem w czym problem.