Małe pytanie - jeżeli dla klucza podstawowego z numerem użytkownika ustawię opcję 'Auto Incremental' to czy:

1. Numeracja będzie się zmieniać automatycznie przy różnych operacjach (np. usunięciu użytkownika), tak, że wartości kolejnych rekordów będą zawsze tworzyć ciąg liczb naturalnych (1,2,3,...)?

2. Czy przy takich zmianach klucze obce w innych tabelach również będą się odpowiednio zmieniać?

nie



to zalezy
http://dev.mysql.com/doc/refman/5.1/en/inn...onstraints.html
on delete, on update

Stosując on delete, czy on update, można sobie samemu krzywdy narobić... Także nie polecam.

Poczytałem trochę, podumałem, ale dalej nie jestem w stanie niczego wymyślić. Poniżej treść mojego posta z innego forum:

OK, narazie jest fajnie, jednak wszędzie temat jest opisany dosyć ogólnikowo, w związku z czym proszę o pomoc.

Udało mi się dowiedzieć, że chodzi tutaj o kod ON DELETE i ON ACTION w kodzie SQL.

Chciałbym się dowiedzieć, jaki będzie prawidłowy kod SQL tworzący tabele bazy danych w moim przypadku. Chciałbym, aby w sytuacji, kiedy zostanie usunięty lub zmieniony numer ID użytkownika, klucz obcy w tabeli str_messages_receivers został usunięty lub nadpisany.

Fragment diagramu EER (klucze podstawowe to klucze , a obce to czerwone romby):



Kod dla tabeli str_users:

[SQL] pobierz, plaintext 
CREATE  TABLE IF NOT EXISTS `starter`.`str_users` (
  `user_id` INT NOT NULL ,
  `name` VARCHAR(50) NOT NULL ,
  `username` VARCHAR(20) NOT NULL ,
  `password` CHAR(40) NOT NULL ,
  `mail` VARCHAR(50) NOT NULL ,
  `access_id` TINYINT NOT NULL ,
  `ban` TINYINT(4) NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`user_id`) ,
  INDEX `users_to_groups_access_access` (`access_id` ASC) ,
  CONSTRAINT `users_to_groups_access_access`
    FOREIGN KEY (`access_id` )
    REFERENCES `starter`.`str_groups_access` (`access_id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB
[SQL] pobierz, plaintext 

Kod dla tabeli str_message_receivers:

[SQL] pobierz, plaintext 
CREATE  TABLE IF NOT EXISTS `starter`.`str_message_receivers` (
  `message_id` INT NOT NULL ,
  `user_id` INT NOT NULL ,
  `read` TINYINT(4) NULL ,
  INDEX `fk_str_message_receivers_str_messages1` (`message_id` ASC) ,
  INDEX `fk_str_message_receivers_str_users1` (`user_id` ASC) ,
  CONSTRAINT `fk_str_message_receivers_str_messages1`
    FOREIGN KEY (`message_id` )
    REFERENCES `starter`.`str_messages` (`message_id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_str_message_receivers_str_users1`
    FOREIGN KEY (`user_id` )
    REFERENCES `starter`.`str_users` (`user_id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB
[SQL] pobierz, plaintext 

Koniec posta. Chciałbym się również zapytać, czy można jakoś te więzy integralności ustawić w MySQL Workbench, wtedy mógłbym sobie sam popróbować.

ON DELETE CASCADE
ON UPDATE CASDADE


tak mozna



dlaczego ?
ja polecam krzywde mozna sobie zrobic nawet dlubiac w nosie
niezla krzywde mozna sobie tez zrobic trzymajac niespojna baze z nieaktualnymi kluczami

po to sa wiezy integralnosci zeby baza zachowala integralnosc, jesli masz uprawnienia ktore pozwalaja na np. kasowanie/updatowanie rekordow to musisz liczyc sie z tym, ze rekordy zostana skasowane/updatowane tak zeby baza zachowala integralnosc :] inna sprawa, ze warto sie dobrze zastanowic czy to czego potrzebujemy to na pewno jest delete rekordow, a nie zmiana ich(na przyklad) statusu na nieaktywny

Prosty przykład dlaczego nie:

Sklep, produkty, faktury.

Mamy jakis produkt na stanie, dodajemy go do faktury, zostal zdjety z stanu ma teraz ilosc sztuk magazynowa 0, uwazamy ze juz jest nam nie potrzebny, wiec usuwamy go. BUM!
Z faktury znika nam produkt! Tadam! A później urzad skarbowy nas za jaja powiesi.

ok, ale przy takiej konkstrukcji bazy jaka mysle narzuca Twoj scenariusz, po zrobieniu delete cascade nie tyle zniklby produkt z faktur co zniklyby faktury ktore ten produkt mialy produkt z faktur zniklby nawet wtedy gdy cascade by nie bylo, a na dodatek mialbys spaprana baze bo faktury przy zlaczeni inner i tak by znikly

Kazdy kto kasuje rekordy w ten sposob o ktorym wspomniales zasluguje na pregierz i cascade niewiele tu zmienia, set null mogloby cos zmienic ewentualnie tzn. sprawic ze w pewnych warunkach byloby to dopuszczalne

Program do faktur albo powinien byc zlaczany wiele-do-wielu z magazynem, wtedy kasujesz rekordy z tabeli zlaczajacej, a za skasowanie czegos z tabeli produktow masz dyscyplinarne zwolnienie z pracy(wtedy bez cascade uszkadzalbys wszystkie faktury, z cascade kasowalbys produkt z wszystkich faktur - same faktury dalej by istnialy i bylyby formalnie poprawne) , albo i tak powinien kopiowac wszystkie dane na fakture -> po to ze jak zmienisz nazwe produktu w magazynie to Ci wstecz wszystkich faktur nie miesza W przypadku drugim mozna pozostawic klucze obce wiele-do-wielu, ale raczej jako informacja dla admina bazy danych i wtedy w on delete powinno byc set null, a bez on delete znow masz burdel w bazie

Gdyby nie było on delete cascade, baza by Ci nie pozowoliła usunąć produktu, ponieważ inne pola (klucze obce) pokazywałyby na wartość w tabeli której nie ma, integralność kluczy jest ważnym elementem i Twoją obroną. Także czasami warto się zastanowić nad tym co tak na prawdę robimy.

I rozumiem, że to w tabeli str_message_receivers w tym przypadku?

Cojak, jeśli tak używasz relacji to nic dziwnego ze ich nie polecasz
W tym przypadku na tabele faktura_produkt nalezy zalozyc klucz obcy na produkt z ondelete RESTRICT. Wowczas baza nie pozwoli na usunięcie produktu, który jest przypisany do jakiejs faktury. Relacje to bardzo fajny mechanizm i jak najbardziej nalezy go stosować.

Takie rozwiązanie jest tym bardziej wskazane, że daje nam zabezpieczenie, gdy jakiś "genialny" admin ominie aplikacje i jej logikę i zacznie grzebać bezpośrednio w bazie. Wówczas również gdy będzie chciał bezpośrednio w bazie usunąć produkt, to baza mu na to nie pozwoli, jeśli produkt będzie przypisany do jakiejś faktury