Autor Wątek: [mySQL] Identyfikacja wpisów  (Przeczytany 3317 razy)

Offline kubera

  • Użytkownik
    • Prywatna strona

# Grudzień 04, 2016, 13:49:46
Dobre pytanie, ale Ty znasz najlepiej wymagania projektu.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline LizarD

  • Użytkownik

# Grudzień 04, 2016, 14:39:59
Wymagania są takie:
1. Imiona, Nazwiska, Pseudonimy mogą się powtarzać
2. Przynajmniej jeden typ kontaktu musi zostać zapisany
3. Reszta to dodatkowe informacje które mogą się powtarzać

Offline kubera

  • Użytkownik
    • Prywatna strona

# Grudzień 04, 2016, 15:28:02
Tabela osób, która się przewija w wątku, jest najważniejsza i tak jak koledzy pisali, musi posiadać ID, imiona i nazwisko.
Myślę, że mógłbyś podjąć decyzję, czy jeden duży rekord, czy przez rozbicie na tabele.
Obydwa rozwiązania są OK (moim zdaniem) i do tego możesz przejść z jednego do drugiego.
Wszystko można poprawić kilkoma poleceniami SQL. Grunt w tym, żeby mieć backup. Rozwiązanie kontaktu, dość szybkie, to zawarcie w tablicy nagłówkowej również id typu kontaktu oraz jego treść. Obie kolumny z więzami NOT NULL. Jeśli decydujesz się na jedną tabelę, to też warto stworzyć odpowiednie więzy, że choć jedno pole kontaktu NOT NULL.

Offline LizarD

  • Użytkownik

# Grudzień 04, 2016, 15:41:12
@Up
Czemu ? Nie mogę dodać wpisu skoro nie mam uzupełnionego przynajmniej jednej danej z Osób i Kontaktu.

Offline kubera

  • Użytkownik
    • Prywatna strona

# Grudzień 04, 2016, 15:53:40
Myślałem, że chodzi o kontakty, czyli, że choć jedno pole kontaktu musi być uzupełnione.
Poddaję się :) W sumie omówiliśmy wszyscy dość wiele.

Offline LizarD

  • Użytkownik

# Grudzień 04, 2016, 21:13:46
Wiec ostatecznie bardziej sprecyzuję bo o jednej sprawie nie wspomniałem.
Kontakty zapisane są zależnie od zalogowanego użytkownika, więc dochodzi kolejna tabela Account zawierająca nazwę użytkownika i hasło. Teraz pytanie czy to powinno być tak że każdy użytkownik ma swoją własną tabelę z kontaktami czy wszyscy użytkownicy mają jedną wspólną tabelę tylko że jest dodatkowe pole identyfikujące dla którego użytkownika jest dany kontakt.

Wymagania dotyczące tabeli kontakt są takie:
1. Imiona, Nazwiska, Pseudonimy mogą się powtarzać, aby była możliwość zapisu kontaktu w bazie to przynajmniej jeden typ ( Imię, Nazwisko, Pseudonim ) musi zostać podany.
2. Przynajmniej jeden typ kontaktu musi zostać podany ( Numer, Alt. Numer, E-mail ). Nie ma takiej możliwości aby przypisać jeden Numer, Alt. Numer, E-mail kilku kontaktom, to jest wartość która się nie powtarza dla danego użytkownika lecz w bazie może się powtórzyć z takiego powodu iż kilku użytkowników może mieć tą osobę zapisaną pod innym Pseudonimem.
3. Reszta to dodatkowe informacje

Więc jest sens dzielić to na tabele

Offline kubera

  • Użytkownik
    • Prywatna strona

# Grudzień 04, 2016, 22:13:38
Wiec ostatecznie bardziej sprecyzuję bo o jednej sprawie nie wspomniałem.
Kontakty zapisane są zależnie od zalogowanego użytkownika, więc dochodzi kolejna tabela Account zawierająca nazwę użytkownika i hasło. Teraz pytanie czy to powinno być tak że każdy użytkownik ma swoją własną tabelę z kontaktami czy wszyscy użytkownicy mają jedną wspólną tabelę tylko że jest dodatkowe pole identyfikujące dla którego użytkownika jest dany kontakt.
Zazwyczaj stosuje się dodatkowe pole, nie całą tabelę, tak jest zgodnie z kilkoma postaciami normalnym w relacjach bazodanowych. To widać dopiero podczas korzystania z tabel, gdzie proste zapytanie różni się parametrami, a nie kolejnym podawaniem całego zapytania za każdym razem. Wyjątkiem mogłaby być sytuacja, że podobne tabele w innym schemacie pełnią rolę dla danych w dużym stopniu od siebie niezależnych. Tu również można zamiast schematu dodać tabelę z inną nazwą. Wtedy schematy pracują jak namespace-y.
Czy jest sens dzielić na tabele? Może odpowiedź jest "reszta na dodatkowe informacje".
Ile tego tam się znajdzie? Jeśli może być dowolna ilość, to często warto rozbić.
« Ostatnia zmiana: Grudzień 04, 2016, 22:19:53 wysłana przez kubera »

Offline Rakieta

  • Użytkownik

  • +1
# Grudzień 05, 2016, 19:01:09
Ale przecież wszyscy już Ci napisali.

UŻYTKOWNICY:
id, login, haslo

KONTAKTY
id, id_uzytkownika, imie, imie2, nazwisko, telefon_komorkowy, telefon_stacjonarny, email (itd)


Teraz albo wyszukujesz kontakty dla danego użytkownika na podstawie id_uzytkownika, albo dodajesz dodatkową kolumnę do tabeli UZYTKOWNICY (kontakty), gdzie będziesz przechowywać id z tabeli KONTAKTY,np. "1,12,14".

Jedno jest lepsze ze względu na wydajność, drugie ze względu na wygodę i prostotę. Zdecyduj sam :)

Offline Xion

  • Redaktor
    • xion.log

# Grudzień 05, 2016, 22:55:39
Cytuj
Jedno jest lepsze ze względu na wydajność, drugie ze względu na wygodę i prostotę.
Tak patrze i ciezko jest mi stwierdzic ktore jest ktore...

Offline Rakieta

  • Użytkownik

# Grudzień 06, 2016, 15:17:57
Kieruję się zwykłym rozsądkiem. Ale jeśli masz chwilę czasu możesz wykonać dla nas test i sprawdzić co jest szybsze:

Użytkownik ma id 1

a)
- Pobierz z tabeli UZYTKOWNICY wiersz uzytkownika o id 1 (lub uzyj ciastka/pamieci);
- Wybierz pole 'kontakty': (1,19,32);
- Wyszukaj w KONTAKTY wiersze o id 1, 19, 32;

b)
- Wyszukaj w KONTAKTY wiersze z id_uzytkownika 1;


Mnie nigdy to nie interesowało, biorę to na chłopski rozum. Dowiadywać się jest wolniej niż wiedzieć, więc w przypadku gdyby tabele SQL działały tak samo jak Array, id będzie naszym indexem i wniosek nasuwa się sam.

Chętnie dowiem się jak jest naprawdę.

Jeśli chodzi o wygodę, jasne, że b) jest wygodniejsze i szybsze we wdrożeniu.

Offline TDM

  • Użytkownik

# Grudzień 12, 2016, 17:54:40
Czyli są dwie tabele:

UŻYTKOWNICY:
id, login, haslo

KONTAKTY
id, id_uzytkownika, imie, imie2, nazwisko, telefon_komorkowy, telefon_stacjonarny, email (itd)

id z tabeli Użytkownicy to id_uzytkownika w tabeli Kontakty. Ale id z tabeli użytkownicy to wartość auto_increment i id z tabeli kontakty to też wartość auto_increment bo muszę jakoś rozpoznać ten wpis w razie jego usunięcia bądź edycji. auto_increment dla tabeli użytkownicy zaczynam np od 1 ale już nie użyje tej wartości dla tabeli Kontakty, tylko mam drugie auto_increment ?

Offline Karol

  • Użytkownik

# Grudzień 13, 2016, 00:29:20
Ogólnie tak, choć wydaje mi się, że trochę dalej Ci się miesza, bo piszesz o nie używaniu wartości 1 jako id w tabeli kontaktów skoro już to jest użyte w tabeli użytkowników. A to nie tak.

Wyobraź sobie autoincrement jako np. numer wiersza w arkuszu, a te dwie tabele jako dwa arkusze. Każdy arkusz ma swoje własne numery wierszy. Jedyna różnica jest taka, że przy usuwaniu wiersza nie zmieniasz numeracji pozostałych wierszy, tylko masz "dziurę".


CREATE TABLE `users` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`login` VARCHAR(50) NOT NULL,
`password` VARCHAR(200) NOT NULL,
PRIMARY KEY (`id`)
);

CREATE TABLE `contacts` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`user_id` INT(11) NOT NULL,
`imie` VARCHAR(50) NULL,
`nazwisko` VARCHAR(50) NULL,
-- reszta pól
PRIMARY KEY (`id`),
INDEX `FK_users` (`user_id`),
CONSTRAINT `FK_users` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`)
);
« Ostatnia zmiana: Grudzień 13, 2016, 00:39:07 wysłana przez Karol »

Offline TDM

  • Użytkownik

# Grudzień 17, 2016, 09:14:16
W sensie "dziure":

TABELA dla użytkowników:
PRIMARY KEY - auto_increment

TABELA kontaktów
PRIMARY KEY - auto_increment

Jak zostanie dodany użytkownik to wartość auto_increment zwiększa się o jeden, owy użytkownik doda kontakt to wartość auto_increment zwiększa się kolejno o jeden i zostanie dodany nowy użytkownik to wartość jego PRIMARY KEY nie będzie wynosić np. 2 tylko wartość auto_increment ? To jest owa dziura ?



Offline Xion

  • Redaktor
    • xion.log

# Grudzień 17, 2016, 13:35:37
Kolumny auto_increment są niezależne od siebie, tj. każda liczy osobno. "Dziury" powstają jedynie w przypadku usuwania rekordów.

Offline LizarD

  • Użytkownik

# Grudzień 18, 2016, 19:02:09
I rozumiem że owymi "dziurami" mam się nie przejmować ?

Pytanie hipotetyczne, co jeżeli baza miałaby być dosłownie ogromnych rozmiarów, to z tymi dziurami ? I jeżeli istniałoby np. kilka tysięcy takich dziur ? Nie jest to jakieś marnotrawstwo ? Może żeby temu zapobiec przydałaby się kolejna tabela z wolnymi/poprzednimi/usuniętymi wartościami auto_increment ?