Odczyt, zapis, modyfikacja danych w MySQL

0

Jestem początkujący jeśli chodzi o MySQL-a. Mam pytanie o to, w jaki sposób prawidłowo odczytywać, zapisywać, modyfikować dane w bazie MySQL?

Już piszę dokładniej, o co mi chodzi.

Założmy, że mam 1 tabelkę w bazie MySQL o nazwie filmy, struktura jak poniżej: (kolumny)

| id_filmy | tytul | gatunek | rok | opis | okladka |

Teraz, takie informacje, jak gatunek, rok będą się dla co niektórych filmów powtarzać, będziemy mieć np 15 filmów z roku 2008, 7 z roku 2009 itp.

Podobnie będzie dla gatunku, bedzie kilka czy więcej filmów typu np. komedia, innych.

Z tego co wiem, w takim przypadku można takie kolumny wyciągnąć z tabeli i utworzyć z nich oddzielne tabele, żeby zmniejszyć redundancję danych:

tabelka filmy (po zmianie):

| id_filmy | tytul | id_gatunek | id_rok | opis | okladka |

tabelka gatunek:

| id_gatunek | gatunek |

i tabelka rok:

| id_rok | rok |

Teraz, jeśli chodzi o odczyt danych z takiej struktury, wiem, że robi się to za pomocą operatora JOIN i to jest dla mnie proste.

Nie bardzo wiem, w jaki sposób zapisywać dane w takiej strukturze, korzystając np z formularzy na stronie www (html + php), podobnie z modyfikowaniem danych.

Jeśli ktoś wie, proszę o pomoc.

0
Romek C. napisał(a)

i tabelka rok:

| id_rok | rok |

Rozumiem, że dane w tej "tabelce" (WTF jest "tabelka"?) będą wyglądały mniej więcej tak:

| id_rok | rok |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
...
| 2008 | 2008 |
| 2009 | 2009 |
| 2010 | 2010 |

Hmm... Genialnie!

A co do wprowadzania danych - na formularzu pewno będziesz miał jakieś pola tekstowe do wpisywania tytułu i opisu, a listę gatunków w jakimś dropdownie, prawda? Więc wystarczy do tabeli film wstawić dane z pól tekstowych + id wybranego w dropdownie gatunku.

0

Dzięki za pomoc!

Jeśli chodzi o tabelę 'rok' to aż taka duża to ona nie będzie, skupiam się na okresie od 1990 do 2010 więc indeks 1 będzie wskazywał na rok 1990.

0
Romek C. napisał(a)

i tabelka rok:

| id_rok | rok |

8-O

0
Romek C. napisał(a)

Dzięki za pomoc!

Jeśli chodzi o tabelę 'rok' to aż taka duża to ona nie będzie, skupiam się na okresie od 1990 do 2010 więc indeks 1 będzie wskazywał na rok 1990.

Słyszałeś o czymś takim jak sarkazm?

Przecież Twój pomysł jest godny perełek - zastanów się nad nim:

  • Nie ma sensu coś takiego jak id_rok, bo rok sam w sobie ma wartość unikalną, więc może być kluczem. Po co dodatkowa kolumna?
  • Nie oszczędzasz na rozmiarze bazy, bo w tabeli film będziesz musiał mieć id_rok (int), które będzie prowadziło do tabeli rok: id_rok (int), rok (int), do tego dochodzą indeksy. W normalnej wersji miałbyś tylko kolumnę rok (int) w tabeli film. No niby możesz użyć czegoś mniejszego na id_rok, ale wiele to nie zmieni.
  • I najważniejsze - zapytania będą bardziej skomplikowane i wolniejsze, bo będzie wykonywane niepotrzebne złączenie.
0

Dobrze, zrobię jak piszesz, kolumna rok wróci do tabeli filmy .

rozumiem, że tabela gatunki jest dobra, czy kolumna tej tabeli gatunk powinna wrócić do tabeli filmy ?

Cel jaki chcę osiągnąć to zmniejszenie do minimum powtarzania się tych samych danych.

0

Ale po co? Stosowanie tabeli slownikowej musi z czegoś wynikać. Co za różnica czy powtarzać ci się będzie Id_gatunku czy jego nazwa? Dokładasz sobie tylko zbędne dane i tabelę, a korzyści żadnej z tego nie ma.
Jeśli nazwa gatunku moze ulec kiedyś zmianie to faktycznie byłoby to uzasadnione, ale w tym przypadku raczej nie jest.

Kiedy byłoby uzasadnione? Np. gdybyś robił bazę studentów danej uczelni. Zamiast przypisać każdemu z nich nazwę wydziału (która czasami ulega zmianie i miałbyś anomalię przy aktualizowaniu bazy, bo trzeba by szukać studenta z daną nazwą i ją zmieniać, a jak gdzieś nazwa była np. z małej litery to by nie zmieniło itd) mógłbyś przypisać tylko ID wydziału a w tabeli Wydziały mieć ID i nazwę. Wtedy aktualizacja nazwy sprowadziłaby się jedynie go zmiany w tabeli słownikowej.

0

@Shalom - przykład z filmami i gatunkami jest identyczny jak przykład ze studentami i wydziałami, zwłaszcza biorąc pod uwagę argument różnie pisanych nazw.
Słownik gatunków, których jest kilka dla wielu filmów ma jak najbardziej sens, na tym słowniki polegają.
Nie wspominając o normalizacji i tych wszystkich bazodanowych teoriach, które przecież tak uwielbiasz.

0

@up nie do konca sie z tobą zgodzę. Co prawda argument o różnej pisowni nazw gatunków jest faktycznie dość ciekawy i nie pomyślałem o tym ;) Ale rożnica między gatunkiem i wydziałem jest dość spora. Nazwa wydziału może się zmienić, dlatego trzeba zrobic tabelę słownikową (inaczej mamy anomalię przy aktualizacji), a nazwa gatunku nie bardzo chyba się zmienia. Tym bardziej chyba nie dochodzą specjalnie nowe gatunki, ale głowy nie dam, nie znam się na tym ;)

Bo idąc zgodnie z twoją logiką należałoby też robić tabele słownikową np. dla nazw miesięcy albo dni tygodnia, a przyznasz ze nie jest to do końca sensowne? Już fakt tabeli słownikowej np. dla nazw miast (kiedy musisz przechowywać dane adresowe) jest sporny ;) (a byłby uzasadniony bo znów byłaby anomalia przy aktualizacji gdy nazwa miasta by się zmieniła)

0

Co do nazw miesięcy czy dni tygodnia, to jak najbardziej. Chociaż na dobrą sprawę wystarczyłoby trzymać jedynie numer miesiąca/tygodnia.
Co do miast - ludzie, którzy nie zrobili w bazach tabeli na nazwy miast zazwyczaj bardzo szybko i mocno zaczynali tego żałować.

Tabela słownikowa to bazodanowy odpowiednik enuma. Definiuje zbiór pewnych wartości, które będą używane w innych tabelach. Nigdzie nie spotkałem się z tym, żeby konieczne dla tabel słownikowych było przechowywanie danych, które się zmieniają. Są one po to, aby przechowywać dane (zazwyczaj tekstowe), które powtarzałyby się w wielu miejscach tabeli "głównej" (implikując brak 3NF, zgadza się?).

Ale ok, zlikwidujmy tabelę gatunki. Jak w takim razie rozwiążesz problem przypisywania filmu do gatunku? Użytkownik będzie miał textbox, do którego będzie mógł wpisać, co chce zamiast kulturalnego dropdowna?

0

Jeśli chodzi o te dane które mogą się zmieniać to jest raczej taki warunek w drugą stronę, tzn jeśli takie dane mogą ulegać zmianie to absoltunie trzeba zrobić tabelę słownikową ;)
A ten brak 3NF nie jest taki oczywisty ;) Bo w takim wypadku musiałbyś mieć też tabele słownikowe dla imion (no bo jest ich dość ograniczona ilość i często się powtarzają) czy dla ulic (one też bardzo często się powtarzają) i zaraz by się okazało że niemalże każde pole powinna zastępować taka tabela. Trzeba z głową do tego podchodzić ;)

Nie mylmy bazy danych z API. Przecież user nie loguje się do SZBD bezpośrednio i tam nie wstawia tych danych, tylko pomiędzy nim a bazą jest jakiś interfejs. To czy ktoś sobie w tym interfejsie zrobi comboboxa czy cokolwiek innego to jego sprawa. To też eliminuje możliwość wstawienia blędnych danych (chociaz nadal ktoś z dostępem do bazy może ręcznie dodać złe dane)

0

Gatunki też mogą się zmienić. A co jeśli do tej pory istniał gatunek komedie, a teraz użytkownik postanowi dodać np. komedie kryminalne, a stare komedie przemianować na komedie romantyczne. Lepiej jest wyciągnąć te nazwy z bazy niż uwzględniać zmiany w API. Choć co do wyciągania nazw to argument może nie do końca przemawia za dzieleniem bo z tablicy filmy też można by distinctem nazwy gatunków wyciągnąć

0

Hallo Romek C.!

Jak piszesz jestes poczatkujacym. Dlatego mysle, ze na tym etapie jest Ci potrzebna jasna i krotka informacja zamiast dlugich i skomplikowanych wywodow na temat teorii relacjonalnych baz danych. Ja nie jestem zadnym profesjonalista, mimo to chcialbym Ci podpowiedziec, ze:

tabelka gatunek:

| id_gatunek | gatunek |

i tabelka rok:

| id_rok | rok |

Obie tabele sa, mowiac trywialnie, odwzorowaniem 1:1. Sorry, ale to jest bardzo zly pomysl i do tego nie ma sensu. Zapomnij o nim.

Moim zdaniem tworzenie tego typu dodatkowych tabel mialoby sens tylko wtedy, kiedy chcialbys przechowywac w nich jeszcze inne informacje. Na przyklad w tabeli "Gatunek" jego opis, kto i kiedy go stworzyl, kto go reprezentuje (rezyserzy) itd. itp.

Do tabeli "Rok" trudno mi znaleŹĆ jakies sensowne rozszerzenie. Dlatego zrezygnowalbym z niej.

Pozdrawiam
Markus
:-)

0
MarkusB napisał(a)

Na przyklad w tabeli "Gatunek" jego opis, kto i kiedy go stworzyl, kto go reprezentuje (rezyserzy) itd. itp.
:-)

A tych reżyserów to jak niby chcesz umieścić? W jednej kolumnie, czy powielając krotki? Weź ty się najpierw zastanów zanim rzucisz jakieś rewelacje. A tabela gatunek jest kwestią sporną. Jeżeli założymy, że nazwy się nie zmienią to można by trzymać gatunek w tabeli film, ale ja osobiście listy tekstów (jak np lista gatunków) wolę trzymać w osobnej tabeli. Bo nawet jak nie zmienią się nazwy gatunków to, idąc za Twoim wywodem, projektantowi może przyjść do głowy dodanie kolumny opisującej gatunek. I teraz powiedz mi do jakiej tabeli łatwiej będzie to dodać? Filmy czy gatunki?

0

@Shalom - zdawało mi się, że Ty informatykę studiujesz, a coś mi tu filozofią zajeżdża. ;)

Tabela słownikowa dla imion - też niby można, ale nigdzie nie widziałem. Pewno dlatego, że w bazie możesz mieć każdą osobę z innym imieniem i taka tabela traci wówczas sens. Natomiast każdy gatunek filmowy będzie powiązany zazwyczaj z wieloma filmami, więc to całkiem inna sprawa.
Tabela ulic - czemu nie? W takiej np. agencji nieruchomości pracownik musi mieć możliwość wyboru istniejących ulic dla konkretnego miasta, tak samo jak powiatów dla województw czy gmin dla powiatów.

Przecież user nie loguje się do SZBD bezpośrednio i tam nie wstawia tych danych, tylko pomiędzy nim a bazą jest jakiś interfejs.

Jest jakiś interfejs, który jakoś trzeba zrobić, jakoś obsłużyć i jakoś zapewnić integralność i jednoznaczność danych w bazie. Ale albo robimy jakąś bazę danych, jakiś interfejs i jakoś to działa albo podchodzimy z głową i robimy porządnie.

Akurat tabelę słownikową łatwo programowo obsłużyć i podpiąć do interfejsu, a zapewnienie integralności i jednoznaczności danych mamy w tym przypadku automatycznie.
Masz jakiś pomysł jak ograniczyć użytkownikowi możliwość wprowadzania danych do określonego z góry zbioru, jeśli nie przez listę wyboru? Pamiętaj, że na początku tablica filmów jest pusta, więc nie możemy się posiłkować danymi z niej. :)

ilo napisał(a)

Choć co do wyciągania nazw to argument może nie do końca przemawia za dzieleniem bo z tablicy filmy też można by distinctem nazwy gatunków wyciągnąć

Możemy wyciągnąć, jeśli już jakieś filmy tam są. Ale załóżmy, że są i robimy distincta. Fragment wyniku zapytania będzie wyglądał mniej więcej tak:

komedia
komedja
kmoedia
Komedia

Każdy wie, o co chodzi, więc wszystko jest ok, nie?
Co z tego, że mamy w bazie 4 komedie, 3 komedje, 2 kmoedie i jedną Komedię zamiast 10 filmów gatunku, o który chodziło użytkownikom?

ilo napisał(a)

A tych reżyserów to jak niby chcesz umieścić? W jednej kolumnie, czy powielając krotki?

No jak to jak? Będziemy dynamicznie dodawać kolumny. :d

Mam lepszy pomysł - jedna baza = jedna tabela. A co! ;)

0

@somekind ja wiem o co ci chodziło i napisałem zresztą że zakładając argumentację Twoją i Ilo można by tą tabelę slownikową z gatunkami faktycznie tam zrobić.
Chciałem tylko pokazać że nie zawsze należy automatycznie tak robić, ale czasami warto pomyśleć czy jest sens. Jak z tymi imionami ;) Równie dobrze można by uznać że mozesz mieć w tabeli filmy różnych gatunków i ta tabela też straci sens ;) (nie ma sensu zakladać szczególnego, mało prawdopodobnego przypadku :) )

z tym jedna baza = jedna tabela to już przecież było kilku na forum co takie rozwiazania proponowali (jeden coś pisał ze "jakbym robił taką bazę żeby sprzedać komuś to bym walnął jedną dużą tabelę" :P).
byli tez tacy co by proponowali nową tabelę dla każdego filmu :)

0

@up - A w Krakowie, to pań przodem się nie puszcza? ;)

W prawdziwym świecie najpierw się normalizuje, a denormalizuje dopiero, gdy wydajność nas nie zadowala. A bez tabeli gatunki nie zaliczysz żadnego kolosa. :)

0

Możemy wyciągnąć, jeśli już jakieś filmy tam są. Ale załóżmy, że są i robimy distincta. Fragment wyniku zapytania będzie wyglądał mniej więcej tak:

komedia
komedja
kmoedia
Komedia

Każdy wie, o co chodzi, więc wszystko jest ok, nie?
Co z tego, że mamy w bazie 4 komedie, 3 komedje, 2 kmoedie i jedną Komedię zamiast 10 filmów gatunku, o który chodziło użytkownikom?

Masz oczywiście rację, nawet już nie myślałam, że przecież taki bigos wyjdzie. Tym bardziej przemawia to jednak za osobną tabelą, żeby nie trzeba było o zmianach w API pamiętać po zmianach w gatunkach

0

To ja napiszę jak ostatecznie zrobiłem...

Kolumna rok wróciła na swoje pierwotne miejsce do tabeli filmy , mimo to dane do tej kolumny nie są pobierane z pola INPUT tylko z menu drop down, którą bardzo łatwo można sobie wygenerować w PHP.

Zastosowanie listy wyboru ma wiele plusów, najważniejszy to ograniczenie użytkownikowi możliwości wpisywania bzdur, co mogłoby mieć miejsce w przypadku pól INPUT.

Poza tym można by w takim przypadku pominąć nawet walidację danych, gdyż użytkownik nie ma możliwości modyfikowania danych, może jedynie wybrać to co ma na liście.

No chyba, żeby ktoś przekazywał te dane przez GET a nie przez POST to wtedy można by próbować przeprowadzić atak poprzez modyfikowanie danych w pasku adresu..

Co do tabeli gatunki , zdecydowałem że jednak ta tabela będzie. Co prawda nazwy gatunków się nie zmieniają, ale łatwo z takiej tabeli wygenerować sobie kolejnego drop down'a poza tym jak będę chciał dodać nowy gatunek, to wystarczy, że zrobię jednego INSERTa i gotowe, nowo dodany gatunek będzie automatycznie dodany do menu drop down..

Bardzo wszystkim dziękuję za pomoc!

0

Poza tym jeden problem się rozwiązał, a powstał kolejny :) Może będę musiał założyć nowy wątek, ale zaryzykuję i napiszę tutaj...

Chodzi o kodowanie naszych polskich znaczków.

Jeśli chodzi o soft jakiego używam to jest to: (bez wdawania się w szczegóły konfiguracyjne)

  • Apache 2.2.15
  • PHP 5.3.2
  • MySQL-6.0.11

Problemem jest to, że polskie znaki po zapisaniu w bazie danych są wyświetlane jako ? . Próbowałem już różnych rzeczy, dodam np, że jeśli używam Windows 7 to w samych stronach muszę używać kodowania windows-1250 bo zarówno utf8 jak i iso-8859-2 nie wyświetlają poprawnie polskich znaków na stronie (bardzo dziwne).

Jeżeli chodzi zaś o sam serwer MySQL to tutaj po zainstalowaniu miałem domyślnie:

  • plik my.ini (default-character-set=latin1, zarówno w sekcji CLIENT jak i SERVER)

Program, którego użyłem do stworzenia diagramu bazy danych (w nim też wygenerowałem kod) to MySQL Workbench.

Workbench domyślnie ustawia zarówno dla bazy jak i dla tabel kodowanie latin1_swedish_ci .

Kolejna dziwna sprawa, nie wiem co język szwedzki ma wspólnego z naszym...

Wiele osób ma problem z poprawnym kodowaniem polskich znaków, mnie to niestety nie ominęło.

Wole się Was tutaj zapytać, może ktoś z Was wie, ja zmarnowałem pół dnia, przejrzałem fora w Internecie i nic

0

Dodam, że moim zdaniem problem jest z serwerem MySQL ponieważ, jak się do niego zaloguję i wykonuję zapytania w terminalu to tam także nie wyświetla poprawnie polskich znaków.

Serwerowi Apache czy interpreterowi PHP chyba nic do tego, bo kodowanie na stronie www ma się nijak do tego co i jak przekazuję do MySQL'a

Co innego dane jakie są przekazywane w zapytaniach i tutaj jeśli zapisywane są polskie znaki to koniec końców wyświetla mi je jako znaki zapytania (?)

Help me please

0

Hallo!

ilo napisał(a)

A tych reżyserów to jak niby chcesz umieścić? W jednej kolumnie, czy powielając krotki?

To zalezy od tego czy w bazie danych przewidywana jest osobna tabela dla rezyserow czy nie.

Pozdrawiam
Markus

1 użytkowników online, w tym zalogowanych: 0, gości: 1