Witam, zaczynam zabawe z php i mysql. Probuje zrobic jakas dosc zlozona jak dla mnie strone, lecz zabawa zaczyna sie od bazy danych. Powyzej przedstawiam stworzona przezemnie strukture. Wlasnie co do niej mam kilka pytan. Bo tlumaczono mi ze relacja sa to powiazania ze soba tabel i raczej powinny byc powiazane ze soba wszystkie tabele... (chyba). Tylko w moim schemacie jakos tak nie chce wyjsc.

-Udalo sie wszystko z tabela users, lecz teraz tabela przepis i tu jest pies pogrzebany.
- Chce zeby kazdy przepis mial jakies produktu(kilka) na a jesli powiaze te tabele relacja (przepis-produkt) to bedzie tak ze jeden przepis jeden produkt. Ta sama sytuacja z kategoria. Przeciez moge przepis przypisac do wielu kategorii.
- Analogia z porada. (porada-kategoria)

Slyszalem ze istnieje cos takiego jak relacja jeden do wielu ale nie wiem jak to zastosowac w tym przypadku.
Prosze o pomoc. Uzywam najnowszej wersji xampa a ss jest z widoku projektu teoretycznych tabelek.

Dla Ciebie tutaj potrzebna jest relacja wiele-wiele

Musisz utworzyć tabelę np. przepis_produkt o kolumnach przepis_id, produkt_id

Analogicznie kategorie

a taka tabela nie musi miec juz pola do inkrementacji np przepis_produkt_id czy cos takiego?



z tej listy jest cascada najlepsza? bo ponoc to jest takie uniwersalne

czy w ten sposob jest poprawnie?

Nie stosuj prefixów do nazw kolum w postaci nazwy tabeli...

Nie nie musi mieć autoincrement, a nawet nie powinna, bo jest to m.in. bez sensu.

Cascade spowoduje usunięcie rekordów jeśli usuniesz produkt lub kategorię (usunie z tej tabeli łączącej.

Mowiono mi gdzies ze tak powinno byc bo to profesjonalniej, to teraz juz zle?oO to jak to wkoncu?Wiem mozna sie pogubic ale stusuje sie do rad ludzi.
// to chyba dlatego ze wtedy by byly relacje id do id i nie wiadomo o co by chodzilo

btw. Stworzona struktura bedzie raczej dzialac?

Profesjonalniej? Nazwy kolumn masz polskie, nazwy tabel angielskie, prefixy kolumn w postaci nazwy tabeli? Beee....

Nie wiem jaki "Profesjonalista" Ci proponował takie rozwiązania ale lepiej zmień znajomości. Jak by Ci powiedzieli że możesz stosować polskie znaki w nazwach kolumn i tabel bo to chroni przed atakami z USA i Korei to też uwierzysz ? Ja rozumiem że człowiek się uczy, testuje, próbuje. Cieszę się bardzo że robisz coś sam i przychodzisz z problemem. Chwała Ci za to.

Teraz do rzeczy.
- nazwy tabel, kolumn - angielskie nazwy.
- nazwy tabel raczej snake_case
- kolumny tak samo
- nazwy tabel liczna mnoga, kolumny pojedyncza
- żadnych prefiksów w nazwach kolumn (po co sobie utrudniać potem życie, możesz zawsze nadawać aliasy tabelom/kolumnom)

To są moje subiektywne nazewnictwa ale wiele, wiele, wiele ludzi tak stosuje. Jest to czytelne, zrozumiałe i nie powoduje problemów.

co do relacji to przecież jest jasna
: users.id -> user_id
: categories.id -> category_id

nie ma nic skomplikowanego, a im prostsze nazwy tym łatwiej się połapać.

no ok ale jak mam np powiazanie pomiedzy tabelami i teraz jest np.

users_id(tabela users) powiazane z dane_users_id(tabela przepis) to pomijajac czy polska czy angielska nazwa

w tabeli dane users id bylo by:
id -> incrementowane(glowne)
id -> id foregin do tabeli userow - ale ta nazwa odpada jak to wtedy nazwac?

jak cos jeszcze to
id_users
czy
users_id?





czy napewno np.
nie category tylko categories? tak dziwnie chyba

Nie rozumiem o co Ci chodzi.

Liczba mnoga bo tabela przechowuje wiele encji czyli entities, a każdy rekord to entiti czyli encja.

user_id - bo odwołujesz się do tabeli user o polu id,
jak by było id_users to w prawdzie do kolumny id w tabeli users, ale mniej logicznie. Najpierw idziemy od ogółu potem do szczegółu

zastosowalem sie raczej do wszystkich wskazowek wyszlo cos takiego:



czy to jest wporzadku?

-tylko tak, stosowalem tak roznie raz cascada , raz nie.
- nie wiedzialem ze nie da sie nie zastoowac nic.

czy te kolory lini maja jakies znaczenie czy wynikaja wlasnie z tego? i prosil bym wlasnie o przyklad gdzie powienienem zastosowac cascade a gdzie nie i mzoe gdzies restricet(odnoszac sie do przykladu)

Na pewno z czegoś wynikają kolory ale to już trzeba w programie zapytać

CASCADE mówi tyle że jesli spróbujesz usunąć wiersz z tabeli users to usuną się także rekordy powiązane bezpośrednio z nimi.
RESTRICTED natomiast odwrotnie. Jeśli będziesz chciał usunąć z users rekord to NIE pozwoli bo są właśnie powiązania i najpierw je musisz usunąć.
NONE czyli nic nie robi
NULL to po po prostu wrzuca NULL do powiązanej tabeli zamiast ID.

pomiedzy users a users_info powinno byc cascada bo usuwa jedno i drugie ? - to raczej na pewno
lecz
pomiedzy users a recipe?
jak dam cascade to usunie usera usuwajac przepis?
jak dam restricted nie usunie przepisu bo users bedzie istnial(paranoja)
jeszcze cos innego? czy nie bardzo zrozumialem? wytlumaczysz mi ten przyklad

W Przypadku CASCADE i Recipes to chodzi o to że samo w sobie Recipes zostanie ale zostanie usunięte powiązanie Recipes <-> User.
Czyli Przepis będzie sierotą bez autora.

Co do RESTRICTED to nie... Chodzi o to że Nie usuniesz Usera dopóki ma powiązane receptury. (mówię tutaj o Tabeli users -> recipe_user)

czyli tam musi byc restricted

I tak zaraz przyjdzie @nospor albo inny wygadany i powie żem głupoty popisał

Ja to widze tak.

R- to restricted
C- cascada

Wydaje mi sie ze cascada moze byc tylko w tym jednym miejscu. Analizujac ten przyklad to tak naprawde cascady mozna by wgl nie uzywac i wszystko jechac restrict.
BO:
nie mozna miec przepisu bez uzytkownika
nie mozna miec danych bez uzytkownika
nie mozna miec kategori przepisu bez samego przepisu itd itd..?

Tylko nie wiem czy ja to prawidlowo rozumuje

Nie do końca. Cascade użyjesz np. dla user_info, bo usuwając usera chcesz żeby usunęło się jego info, natomiast user - recipe jako Restricted bo nie chcesz usunąć usera jeśli ma recepty.

http://zasoby.open.agh.edu.pl/~09seenglert...tawy&menu=3

wydaje mi sie ze teraz jest ok , interesuje mnie tylko relacja pomiedzy takimi tabeliami jak recipe_image a image np. czyli z ta relacja wiele do wielu, w takim wypadku jest cascada bo kasuje wszystko
przepis razem z obrazkiem czy raczej restrykcyjnie (przeciwnie) mozna usunac obrazek zachowujac przepis wiec restrit.

Cascade, bo obrazki Ci nie będą więcej potrzebne. I tutaj raczej bym zamiast tabeli recipe_image dodał po prostu kolumnę recipe_id w images. No chyba że obrazek szarlotki będziesz stosował też do bigosu

Ogólnie jest ok. Ważne jest to abyś wiedział dlaczego stosujesz daną relację (1:1, 1-n, n-1, n-n) i jakie FK zakładasz do tego. Tu musisz sobie zadawać pytanie czy coś może być usunięte jeśli jest powiązane z czymś lub czy chcesz usunąć coś wraz z powiązanymi relacjami.

tylko ze z image(tej samej) maja kozystac tez news i tips, wiec jesli dodam kolumne recipe_id do image to tak troche jak z kosmosu bedzie sie miala do tamtych dwoch tabel

moglbym teoretycznie w tabeli image -> pole type (bo tach chcialem wstepnie) rozpoznawac po tym polu czy to news/recipe/tips ale chyba sie zgubilem jak klucze polaczyc
ALE:
chyba zle nie jest :
BO
np.
Dodaje recipe np 3 obrazki dodaja sie one do tabeli recipe_image (kolejno-zapis o tym) same obrazki wedruja do image
Nastepnie tipsa z 2 obrazkami tips_image(zapisuje jakie) obrazki do image
analogia z news.

Tylko co jesli to beda te same obrazki? bez sensu dawac tu unikaty poprostu tak musi byc.

A tego z ta szarlotka nie kapuje, przeciez dajac przepis na szarlotke z jej zdjeciem nie wykorzystam jej w przepisie z bigosem. No chyba ze pobiore obrazek z image?(o to ci chodzi?)

Dobra niech zostanie jak jest Przekonałeś mnie

czy tabela tego typu powinna miec autonumerowanie? w sensie jeszcze jedno pole na poczatku id(autoincrement)?

Możesz dodać nie zaszkodzi w niczym, a nuż się do czegoś przyda.

Analizujac ssa znalazlem jeszcze jedno pytanie.
Tabele recipe -> recipe_product -> product

czy jest potrzebna tabela product?

dlaczego o to pytam, z zalozenia gdy z formularza uzytkownik podaje skladniki np. zupa ogorkowa:
woda, ogorki, cukier (abstrakcja) sa 3
to
wszystko pojdzie do recipe_product na zasadzie id_recipe ->id_product
ale po co ma to dzialac tak skoro juz nie wykorzystamy cukru z zupy ogorkowej w przepisie na herbate bo to juz bedzie inny przepis

nie wystarczylo by:

recipe -> recipe_product
(tylko te dwie tabele)
tylko recipe_product
dwa pola recipe_id(id przepisu) np zupy ogorkowej oraz pole skladnik(tylko jako text) nie int(ew varchar)

czy w takim przypadku taka tabela musi miec wlasne id? czy wgl ja dobrze to rozumuje

Tu nie chodzi o to czy będziesz cukru używał jeszcze gdzieś.
Traktuj tabelę produts raczej jako swoją szafkę z rzeczami.

Zamiast redukować tabele dodałbym jeszcze za to do tabeli product_recipe kolumny: measure, quantity symbolizujące jednostkę miary i ilość np. 250 g

do product_recipe? a nie do samego product? ze jakis produkt ma takie wartosci?

sa dwie opcje (mowie o wprowadzaniu danych)

1. uzytkownik ma pole formularza
[ ] -> wprowadza nazwe produktu , ilosc i miare i to wszystko jest razem. dosc nie poprawnie i co wtedy?

2. uzytkonim ma pola

[] -> nazwa produktu
[] -> miara
[] -> ilosc

tak duzo lepiej, i co wtedy??

nie charakteryzuje sie samego produktu w samym produkcie tylko w tabeli zlaczajacej?

Produkt to Cukier, a składnik z potrawy to 1 szklna cukru, 1 łyżeczka cukru.

ale zakladajac ze strona bedzie uboga nie bedzie miala nadzoru modow to gdy uzytkownik wpisze
np. szklanka cukru bialego kilo maki , paczka makaronu
to go przpepusci
uzytkownik bedzie gupi i nie wpisze
cukier, maka, makaron a pod spodem np kilo paczka itp

co wtedy?
powraca pytanie z ppoprzedniego posta

wersja 2. Dodajesz autmatem do bazy xxx produktów żeby user miał z czego wybierać.

Jak nie ma produktu to jakiś + z "Nie ma produktu? Dodaj własny"

mam x tys produktow wpisywac do bazy jest cos takiego jak lista produktow ktore moglbym importowac do bazy (cos w pliku txt czy csv)
gdzies dostepne na internecie takie tabele/bazy czy jak to nazwac.. (bo pomysl calkiem fajny)