[mysql] W jaki sposób zapisać dane?

0

Mam baze userów i mam rejestrowac kto zmodyfikowal produkt czyli ogolnie mowiac tworzyc jakby kopie produktu z data i nazwa usera, i teraz moje pytanie jezeli w tabeli users mam id,nazwa to w drugiej tabelce przy produkcie zapisac id usera czy nazwe?
Bo jezeli zapisze id a p[ozniej admin wejdzie w edycje i zmieni nazwe to juz tamta nie bedzie sie pokazywac tylko nowo zmieniona. Jak to sie realizuje?
Znowu fajnie by bylo zapisac nazwe tylko jak nazwa bedzie dluga to zapisywac tyle identycznych danyuch do bazy. Jak to realizujecie?

0

Jezeli jest szansa, ze moze zmienic sie nazwa, to lepiej ja kopiowac. Ale bardziej prawidlowo byloby chyba zapisywac date zmiany, id uzytkownika i reszte danych. Do tego dodatkowa (ta sama?) tabela na zmiany w uzytkownikach rowniez z data. Czyli jezeli chcemy wypisac zmiany to wypisujemy po id i do reszty siegamy do oryginalnej tabeli, chyba, ze istnieje odpowiedni wpis w bazie historycznej. Rowniez mozna uniemozliwic zmiane, a tylko usuniecie uzytkownika i dodanie nowego - wtedy dla nieistniejacych juz wpisow szukaloby sie ich w tabeli/bazie historycznej.

0

Drugi pomysl lepszy, tylko sytuacja taka, przychodzi kobietka i mowi ze zmienila nazwisko i nie moze byc jako drugi user tylko jako jeden wiec co powienien zrobic admin ,wejsc zmienic nazwisko i tyle.
W sumie mozna zastrzec ze nie mozna zmieniac uzytkownika na juz istniejacym tylko jezeli chcemy dodac nowego a stary jakis tam nie potrzebny to usuwamy starego, ja wymyslilem taki sposoc ze mam pole dostep i tu albo tak albo nie, usuniecie usera to nic innego jak ustawienie dostepu na nie. po prostu nie ma takiej mozliwosci zeby skasowac usera z bazy. Mozemy zrobic zeby byl niewidoczny ale nie zeby go calkowicie skasowac. I jezeli bedziemy robic jakis raport gdzie wystepuje "skasowany" user to nie ma problemy bo fizycznie on jest, a jezeli nastapila zmiana nazwiska to nawet dobrze bo wszedzie bedzie poprawna. A jezeli admin mimo to zedytuje usera na nowego to w sumie juz jego problem.
Złe podejscie?

0

Pytanie co znaczy edytowac usera. Najczesciej login a imie czy nazwisko to dwie rozne rzeczy. Login pozostaje niezmieniony (bo i po co zmieniac), a reszta danych niech sie zmienia, bo tu nie ma raczej problemu.

Blokada kasowanie jest w sumie dobrym pomyslem, bo czesto nie ma tak naprawde powodow, zeby kasowac - chyba, ze baza rozrasta sie bardzo szybko czy cos podobnego.

Ja ustalilbym tak, ze istnieja pola w uzytkowniku, gdzie powinny byc zapisywane wszystkie ich zmiany (np. login) i takie, ktorych zmiany nie sa istotne z punktu widzenia administracji (czyli np. imie czy nazwisko).

0

U mnie akurat imie i nazwisko sa bardzo wazne bo aplikacja ma byc uzywana w firmie do rejestracji badan, i ma byc rejestrowana kazda zmiana wpisów , czyli jezeli podchodzi gosc cos uzupelnia o produkcie to ma byc zapisane co i kto zmienia czyli login mi nic nie daja musi byc imie i nazwisko jako identyfikator czyz nie?
Baza userow nie bedzie sie roizrastac bo moze byc max kilkanascie lub kilkadziesiat kont.

Aha i jeszcze jedno pytanie, jest baza produktów , firma je bada i uzupelnia pola takie jak wytrzymalosc, temp topnienia itd.... rozne pola uzupelania inny dział. Mam zrobic tak ze jezeli ktos bedzie edytowal produkt i cos dopisywal to tworzy sie jakby kompia wpisu produktu z data i id usera, czyli jeszeli ktos po raz pierwszy produkt bedzie 1 wpis. Przyjdzie ktos inny zedytuje produkt czyli np dopisze jeden rekord robi sie drugi wpis a ten pierwszy zostaje. Czyli zawsze w wyswietlaniu bedzie najwaznijeszy ten ostatni edytowany, a w histori beda dostepne wszystkie, czyli bedzie lista kto i co edytowal. Dobre rozwiazanie?

0

Czytając Wasze rozważania zastanawiam sie nad jedna rzeczą. Czy pożądane jest aby zmiania nazwiska pani była widoczna w poprzednich wersjach dokumentów? Jeśli tak, to tworząc historię możesz zapamiętac samo id usera i nazwisko wyciągac z tabeli z userami. Jeśli nie to niestety do każdej kopii rekordu musisz dodawac jeszcze nazwisko.

Co do robienia historii poprzez kopiowanie rekordów do jest dobry pomysł. Dobrze jest jeszcze zapamiętac id poprzedniego dokumentu aby odtworzyc całą ścieżkę powstawania ostatecznej wersji. Niestety jest to sposób pamięciożerny ale prosty w implementacji.

Na koniec jeszcze jedno. Zastanów sie czy może zaistniec sytuacja, w której kilku użytkowników bedzie chciało korzystac z tego samego dokumentu. Może to powodowac dośc spore błędy i trzeba się napocic żeby to dobrze rozwiązac.

0

tu rzeb się zdecydować na coś konkretego. Ogólnie to robi się tak, że nie dopuzcza się zmiany "ważnych" danych dla użytkownika (np. imię, nazwisko, nick) a oznacza się go jako nieaktywny i zakłada się nowego. Robi się ta właśnie ze względu na zachowanie integralności danch

0
Misiekd napisał(a)

tu rzeb się zdecydować na coś konkretego. Ogólnie to robi się tak, że nie dopuzcza się zmiany "ważnych" danych dla użytkownika (np. imię, nazwisko, nick) a oznacza się go jako nieaktywny i zakłada się nowego. Robi się ta właśnie ze względu na zachowanie integralności danch

Ale wg Twojej teori jezeli zachodzo potrzeba zmiany nazwiska to jeden user bylby w dwoch rekordach i tak samo w raportach gdy zrobimy raport dla 1 usera (przed zmiana nazwiska) to bedzoe jakby inny user niz ten drugi, a jak dostanies z pytanie prosze wydrukowac co zrobila jedna osoba przez 3 lata to musisz pamietac ze byla zmiana i wydrukowac raport dla 2 userow -przed zmiana i po zmianie.

0
chesti napisał(a)

Na koniec jeszcze jedno. Zastanów sie czy może zaistniec sytuacja, w której kilku użytkowników bedzie chciało korzystac z tego samego dokumentu. Może to powodowac dośc spore błędy i trzeba się napocic żeby to dobrze rozwiązac.

Tak wlasnie ma byc , ktos sie loguje cos zmienia w produkcioe i sie wylogowywuje, za chwile ktos sie loguje z innego dzialu i uzupelnia inne dane. Wszystko ma byc rejestrowane zeby pozniej mozna bylo wydrukowac historie zmian produktu.
Np.

  1. Stal nr 2 rekord1=2 zmiana: AA
  2. Stal nr 2 rekord1=2 rekord2=3 zmiana: BB itd....

Czyli widac ze pole rekord2 dodal user BB a nie AA i jak cos bedzie za to odpowiedzialny.

A w glownej bazieproduktów zawsze aktualna wersja bedzie ta najmlodsza czyli w tym przypadku 2.

0

ja naprawdę nie rozumiem tego tematu bo chyba coś było pokręcone duużo wcześniej - przy obmyślaniu tabel i założeniach tego systemu

no ale może jak jest user w bazie to niech nie ma pola nazwa tylko id aktualnej nazwy, znowu następna tabela - id nazwy, id usera do którego kiedykolwiek była ta nazwa przypisana i sama nazwa a przy produkcie / artykule czy co tam masz - id usera i id nazwy
pole nazwa mogłoby być unikalne to nie dość że dane nie byłyby dublowane to jeszcze jak przyjdzie dwóch Janków Kowalskich ...

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