Dodatkowe kolumny; wydajność bazy; spójność bazy

0

Załóżmy hipotetycznie, że mamy tabelę przechowującą wersje jakiejś encji. Mamy w tej tabeli też kolumnę, która oznacza najnowszą wersję. 1 - najnowsza; null - stara.
Czy nie powoduje to niespójność bazy?

Jak Wy byście to zrobili, aby zoptymalizować przeszukiwanie, aby pobrać najnowszą wersję?

0

nie rozumiem ... znaczy w jednej tabeli masz rekordy i a poprzez jakąś kolumnę określasz ... no właśnie co określasz. Co rozumiesz poprzez wersję ...

0

Mamy np.
OSOBY:
id_oosby,
imię,
nazwisko,
numer telefonu.

Kazdy user moze zmienić sobie imię.

Po edycji dodawany jest nowy rekord
122,
Jan,
Kowalski,
23123123

edytujemy ponownie:
122,
Jan2,
Kowalski,
23123123

Mamy:

122, Jan, Kowalski, 23123123
122, Jan2, Kowalski, 23123123

Żeby znaleźć najnowszą edycję dodajemy kulmnę "aktywny" 1 lub 0
I wyszukujemy:
weź wersję usera o id 122 z "aktywny" = 1.

Czy to jest dobre rozwiązanie?

3

To jest złe rozwiązanie.
Historię zmian odkładaj sobie gdzie indziej.
ID ma byc UNIKALNE

1
M. napisał(a):

Jak Wy byście to zrobili, aby zoptymalizować przeszukiwanie, aby pobrać najnowszą wersję?
Przykładowo dla tabeli KONTRAHENCI zrobiłbym to tak. Dokładam kolejną tabelę KONTRAHENCI_HISTORIA w której przytrzymuję wszystkie archiwalne wersje rekordów. Musi ona posiadać dodatkowe pole WERSJA oraz KONTRAHENT_ID. Natomiast we wszystkich tabelach korzystających z tabeli trzeba mieć pola:
''KONTRAHENT_ID
WERSJA''
Dzięki czemu wiesz jaką wersję rekordu musisz użyć aby wydrukować jakiś archiwalny dokument.

0
M. napisał(a):

Załóżmy hipotetycznie, że mamy tabelę przechowującą wersje jakiejś encji. Mamy w tej tabeli też kolumnę, która oznacza najnowszą wersję. 1 - najnowsza; null - stara.
Czy nie powoduje to niespójność bazy?

Jak Wy byście to zrobili, aby zoptymalizować przeszukiwanie, aby pobrać najnowszą wersję?

Users

  • id
  • pesel
  • inne dane które nie ulegają zmianie

Imiona

  • id_user
  • imie
  • data

Faktury

  • id
  • id_user
  • inne dane faktury

select
u.,
( select imie from Imiona where id_user = u.id order by data desc limit 1) as imie,
f.

from
users as u
join
faktury as f
on
f.id_user = f.id;

Pozdrawiam

0

@artur_bredzki rozwiązanie bardzo słabe. Jak zmienia Ci się 4 kolumny to zrobisz 4 tabele....? Może nie wiesz, ale w przypadku np. faktur dane kontrahenta jak nazwa, NIP czy też adres muszą być nawet po zmianie drukowane jak w chwili wystawienia dokumentu. Twoje zapytanie nie obsługuje tego. Zawsze pobierze najnowszą wersję. Więc co to za przechowywanie zmian?

0
Mr.YaHooo napisał(a):

@artur_bredzki rozwiązanie bardzo słabe. Jak zmienia Ci się 4 kolumny to zrobisz 4 tabele....? Może nie wiesz, ale w przypadku np. faktur dane kontrahenta jak nazwa, NIP czy też adres muszą być nawet po zmianie drukowane jak w chwili wystawienia dokumentu. Twoje zapytanie nie obsługuje tego. Zawsze pobierze najnowszą wersję. Więc co to za przechowywanie zmian?

Odpowiadałem na pytanie: "jak pobrać najnowszą wersję", które zamieściłem w cytacie, a nie co musi być po zmianie drukowania.
Pozdrawiam

0
artur_bredzki napisał(a):

Odpowiadałem na pytanie: "jak pobrać najnowszą wersję", które zamieściłem w cytacie, a nie co musi być po zmianie drukowania.
Ale to rozwiązanie jest trochę nie dobre. W moim rozwiązaniu aktualna wersja siedzi w normalnej tabeli.

0
Mr.YaHooo napisał(a):
artur_bredzki napisał(a):

Odpowiadałem na pytanie: "jak pobrać najnowszą wersję", które zamieściłem w cytacie, a nie co musi być po zmianie drukowania.
Ale to rozwiązanie jest trochę nie dobre. W moim rozwiązaniu aktualna wersja siedzi w normalnej tabeli.

To czy jest dobre, czy słabe, zależy od sposobu porywnywania. Jeśli najczęściej zapytania są po najnowszą wersję, to pewnie że należy najnowszą
wersję trzymać w normlanej tabeli. Chociaż od tego też jest wyjątek, bo jeśli danych jest mało, to po co denromalizować bazę. Jeśli często
będą zapytania o drugą-najnowszą wersję, to nawet się opłąci tę drugą wersję trzymać w normlanej tabeli... Bez statystycznego rozkładu zapytań
ciężko coś więcej doradzić.

Pozdrawiam

0
artur_bredzki napisał(a):

To czy jest dobre, czy słabe, zależy od sposobu porywnywania. Jeśli najczęściej zapytania są po najnowszą wersję, to pewnie że należy najnowszą
wersję trzymać w normlanej tabeli. Chociaż od tego też jest wyjątek, bo jeśli danych jest mało, to po co denromalizować bazę. Jeśli często
będą zapytania o drugą-najnowszą wersję, to nawet się opłąci tę drugą wersję trzymać w normlanej tabeli... Bez statystycznego rozkładu zapytań
ciężko coś więcej doradzić.
Tak masz rację. Jednak w 99% aplikacji będzie się pytało o najnowszą wersję rekordu. Archiwalne będą tylko do podglądania starszych dokumentów. Poza tym nie wiem co innego niż aktualna wersja można trzymać w głównej tabeli.

0

Nie wiem czy 99%. Czasami trzeba wyświetlić raport w którym w kolejnych latach wyświetla się aktualny adres, nazwa, itd.
Pozdrawiam

0

Ale to jest tylko raport. Nie raportujesz przez cały czas. Akurat wiem co mówię, bo mam styczność z taką tematyką i dawno temu zmierzyłem się z tym problemem.

0

To zależy od danego zastosowania. Ja akurat często potrzebuję odpowiednik raportowania w którym są potrzebne akutalne dane z danego okresu.

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