Dyskusja:Tabela (bazy danych)

message: Komentarz, który powinien zostać przeczytany, aby nie brać tego powyżej zbyt dosłownie.
Praktycznie powyższy fragment o kluczach jest w zasadzie prawdą, lecz całe zagadznienie zostało bardzo mocno spłcone. Indeksy bardzo mocno zachaczają o projektowanie baz danych. 
Etap projektowania
Na tym etapie nie mówi się o kluczach głównych i obcych. Mamy tylko klucze kandydujące proste i złożone. Klucze obce pojawiają się dopiero przy tranformacji modelu logicznego na model fizyczny.
Klucz prosty - jest to klucz składający się tylko z jednej kolumny
Klucz złożony - składa się z kilku kolumn
Na każdy klucz kandydujący nakładamy ograniczenie UNIQUE
Jeżeli istnieje klucz prosty należy starać się go transformować na klucz główny. (Tylko z głową. Oczywiście, że  blob też jest kluczem prostym, ale nie wyobrażam sobie w produkcyjnej aplikacji złączeń po blobie) Jeżeli mamy PESEL i aplikację tylko dla polskich klientów to nie powinno się wprowadzać sztucznego klucza głównego.
Jeżeli są tylko klucze złożone, to trzeba dodać sztuczny klucz główny
----
Przenisłem tutaj, bo ma raczej charakter dyskusji. Po pobierznym przjerzeniu nie widzę różnicy między tym co jest artykule, a tym tutaj. W zasdzie nie widzę nawet specjalnych różnic między tym co jest w artykule. Fakt, że nieco uprościłem sprawę, ale nie chciałem wpisywać tu wszystkich zgadnień projektowania baz danych. Jak znajdę opracowanie według którego pisałem sam artykuł, to dodam w źródłach i będzie można podać więcej szczegółów. Nux zostaw notkę 19:09, 13 cze 2006 (CEST)
----
No tak, Po części masz rację, ale podszedłeś do sprawy zbyt upraszczając. (A ja zbyt emocjonalnie do tego podchodząc...)
Sam też nie miałem zbytniej ochoty wchodzić w projektowanie BD. (Tz. na początku miałem (co widać), ale przemyślełem sprawę i mi nieco przeszło). Ale wróćmy do dyskusji... (Sorki napadło mnie i pewnie będę chciał się na kimś odgryść ;) Padło na Ciebie)
Myślę, że warto by było ustalić jakiś poziom na którym musimy się zatrzymać, żeby nie wejśc zbyt głęboko w zagadnienie projektowanie baz danych. Uważam, że powinniśmy tu jedynie wspomieć o kluczach, a powięcej przekierować na właściwy artykuł. Tak sobie myślę o (na rzie tylko tematy):
 - klucze (może bez dzielenia)
 - linki do postaci normalnych
 - znaczenie normalizacji
 - A może by tak etapy projektowania i co się na którym etapie pojawia
Przepraszam, ale mam mieszane uczucia... Zaraz trochę potnę ten artykuł. Przynajmniej na klucze (bazy danych)
Przepraszam nic nie zrobię. Teraz nie ejstm w stanie. Możel epiej od razu usunąc mój komentarz z dziś.  Niestety jestam w takim stanie że nic kreatywnego nie wymyślę. Mogę odpowiadać na pytania (Wczoraj miałem egzamin z projektowania rozproszonych baz danych więc jeszcze sporo umiem ;) )
pBT 17:23, 18 cze 2006 (CEST)
thread_title: Komentarz do artykułu (pierwotnie w artykule)

message: Komentarz Stoka do uwag Nuxa zamieszczonych w dyskusji Stoka. 
Nux: O ile zmianę w tytule przykładu rozumiem jako chęć utrzymania jednej nomenklatury, o tyle skasowania fragmentu o encjach i relacjach nie rozumiem w ogóle.
replies: text: Stok: A było tak: Pojedyncza tabela może być reprezentacją pewnej encji (np. książek, mieszkań, ludzi), relacji między nimi, albo może stanowić zawartość całej bazy danych.

text: Informacja jaką niesie to zdanie, po pominięciu żargonu informatycznego brzmi: Tabelea jest częścią, a może też być całą bazą danych – i po co taki zapis?
replies: text: :Niesie też informacje o tym, że tabele mogą też powstać z relacji między encjami, a nie tylko z encji. Sama encja, to natomiast podstawowe pojęcie z zakresu teorii projektowania baz danych. --Nux (dyskusja) 12:41, 17 gru 2006 (CET)
replies: text: :: Chciałby by w artykule nie było słów niezrozumiałych dla przecietnego studenta "nieinforamtyki".
replies: text: ::: Ech... Podobny problem był poruszany na grafach i większość jednak się zgodziła, że musi być podana formalna definicja gdzieś na początku artykułu. Tutaj na samym początku zresztą język jest dosyć luźny, potem wypada wprowadzić pojęcia, o których każdy może przecież doczytać. --Nux (dyskusja) 13:14, 18 gru 2006 (CET)
 
Nie wiem też co złego było w podkreśleniu, że jest to obiekt teoretyczny? Może słowo "obiekt" nie było tu szczególnie trafione, ale nie mam pomysłu na inne.

text: Nie chodzi o słowo obiekt ale o teoretyczny. Nie jest to obiekt teoretyczny, tabele fizycznie istnieją, tak jak istnieją dane w nich zawarte.
replies: text: :Tu się trochę źle wyraziłem - miałem na myśli to, że tabele nie istnieją fizycznie jako coś zbliżonego do tabele, ale wręcz jako parę struktur, a mogą nawet znajdować się w paru plikach. Tabela może np. po optymalizacji być zachowana jako drzewo. --Nux (dyskusja) 12:41, 17 gru 2006 (CET)
replies: text: :: Sposób przechowywania danych to inny problem.
replies: text: ::: Dokładnie o to mi chodziło - tabela nie jest obiektem reprezentowanym fizycznie, w sposób jaki podpowiadały by to intuicja. --Nux (dyskusja) 13:14, 18 gru 2006 (CET)
No i wreszcie nie rozumiem zmian przy opisie klucza głównego - z Twoich zmian wynika, że nie może to być pojedyncza kolumna, co przecież nie jest prawdą.

text: A co powiesz na zdanie takie, mieszkanie jest obiektem składającym się z pojedynczej lub wielu izb? Albo takie: w firmie jest pojedynczy komputer lub jest wiele komputerów?
replies: text: :Może nie brzmiało by to zbyt dobrze w normalnych warunkach, ale formalnie jeśli w informatyce nie określę, że mieszkanie może się składać z jednego pokoju, to będzie znaczyło, że pojedynczy pokój nie będzie mieszkaniem. --Nux (dyskusja) 12:41, 17 gru 2006 (CET)
replies: text: :: Informatyka jest wyjątkiem w logice?
replies: text: ::: Wręcz odwrotnie - język potoczny nie jest logiczny (stąd zresztą problemy z jego interpretacją). --Nux (dyskusja) 13:14, 18 gru 2006 (CET)
Aha i chciałem spytać, bo ze zmian wnioskuję, że jednak nie zrozumiałem - co masz na myśli przez "położenie w zbiorze danych"? Szczerze mówiąc zastanawiałem się nad usunięciem tego fragmentu, bo to chyba nie ma wiele wspólnego z abstrakcyjnym pojęciem jakim jest tabela w bazach danych...

text: Pojęcie tabela jest tak samo abstrakcyjne jak abstrakcyjne są określenia program, instrukcja, dane. W implementacjach istnieją one rzeczywiście, a nie są tylko abstrakcyjnym modelem.

text: A przez położenie rozumiem położenie danych w pliku, strumieniu danych. Dane w źródle danych są ułożone po kolei, pierwszy, drugi, trzeci itd. rekord, odczytując dane program „wie” który z kolei rekord odczytał, dzięki temu może wykonać zmiany w źródle danych, dowiązać dane z innej tabeli. Taki system stosuje się w wielu prostych systemach baz danch, w wielu programowanych w językach ogólnego przeznaczenia takich jak C, Pascal i inne, stosowany jest też powszechnie w bazach kartotekowych.
replies: text: :no tak, ale żeby znać pozycję muszę mieć jakiś niezależny indeks, albo długość rekordów musi być stała. Poza tym taki indeks można traktować jako klucz, a jak się uprzeć to nawet pozycję w pliku też. --Nux (dyskusja) 12:41, 17 gru 2006 (CET)
replies: text: :: Tak czy siak musi być metoda na odczytanie danch bazy danych i przypisanie ich do tabel, pól i innych srtuktur. Metoda klucza głównego polega na tym, że w rekordzie muszą być dane jednoznacznie identyfikujące rekord, bez względu na umieszczenie tego rekordu w strukturze tabeli. W metodzie bez klucza ważne jest położenie w pliku, ale wówczas przebudowa, odzyskiwanie miejsca po skasowanych rekordach jest utrudniona.
replies: text: ::: Ale to nie jest istotne. Można przyjąć równie dobrze, że id nie jest w tabeli, bo jest np. tylko w strukturze indeksu (chociaż o ile wiem zazwyczaj jest i tu i tu, ale przecież nie musi być). Na tej samej zasadzie pozycję można traktować identycznie jak id (numeryczne) tylko z krokiem przyrostu równym wielkości rekordu, a nie równym 1. --Nux (dyskusja) 13:14, 18 gru 2006 (CET)

text: ::StoK 19:22, 17 gru 2006 (CET)
StoK 08:35, 16 gru 2006 (CET)
thread_title: O treści artykułu