SQL - Joiny wydajność.

Dzień Dobry.

Przedstawiam problem:

Baza danych do zarządzania produktami:
W nim różne tabelki: np: products
products_locales

W products posiadam informację o produkcie (ogólne niezależne od języka) w products_locales posiadam np:
-id
-id_product
-id_locale / id_lang

• name
• desc

I tu pojawia się pytanie: Ponieważ zależy mi też na wydajności bazy (przy odpowiednim obciążeniu)

Posiadam już inną bazę danych np general i w niej już posiadam tabelkę locales (z danymi o językach) i teraz zastanawiam się, czy w products_locales odnosić się do general.locales, czy dla każdego klienta stworzyć również własna tabelkę locales.

Wersja 1 za każdym razem odnosić się do locales z głównej bazy danych locales. (Ryzyko że będzie wolniej działać? Za każdym razem robiąc joina na produkt odnosimy się do tabelki z innej bazy daynch)
Wersja 2 każda baza (każdy klient) ma swoją tabelke locales (wtedy będzie dużo powtarzających się informacji bo każdy klient będzie mieć takie samo locales)

Jakie rozwiązania proponujecie a może macie swoje własne lepsze rozwiązania?

Pozdrawiam

Emil Dworniczak napisał(a):

Dzień Dobry.

Przedstawiam problem:

Baza danych do zarządzania produktami:
W nim różne tabelki: np: products
products_locales

W products posiadam informację o produkcie (ogólne niezależne od języka) w products_locales posiadam np:
-id
-id_product
-id_locale / id_lang

• name
• desc

I tu pojawia się pytanie: Ponieważ zależy mi też na wydajności bazy (przy odpowiednim obciążeniu)

Co to znaczy "wydajna baza danych" i co to znaczy "odpowiednie obciążenie"?

Co do zasady, poprawnie zaprojektowana baza danych świetnie radzi sobie ze złączeniami.
I co do zasady - lepiej ze złączeniami wewnętrznymi niż zewnętrznymi; indeksy na kluczach obcych się kłaniają.
Ale tu trzeba uważać - ile będzie tych języków?
Kilkanaście? Nie ma sensu przy takim zastosowaniu.

poza tym, to o co pytasz to jest po prostu przedwczesna optymalizacja.
Daj spokój i skup się na logice.

Posiadam już inną bazę danych np general i w niej już posiadam tabelkę locales (z danymi o językach) i teraz zastanawiam się, czy w products_locales odnosić się do general.locales, czy dla każdego klienta stworzyć również własna tabelkę locales.

NIE TWORZYĆ ŻADNYCH OSOBNYCH TABEL.

Wersja 1 za każdym razem odnosić się do locales z głównej bazy danych locales. (Ryzyko że będzie wolniej działać? Za każdym razem robiąc joina na produkt odnosimy się do tabelki z innej bazy daynch)
Wersja 2 każda baza (każdy klient) ma swoją tabelke locales (wtedy będzie dużo powtarzających się informacji bo każdy klient będzie mieć takie samo locales)

To jest zdecydowanie poroniony pomysł.

Jakie rozwiązania proponujecie a może macie swoje własne lepsze rozwiązania?

Tak, macie.

1. **Cache **- po co czytać ciągle to samo?
   Poza tym, bazy danych są sprytne i naprawdę potrafią używać cache.
   Ale zawsze lepiej nie pytać bazy o dane, które się posiada.
2. Database shard
   A tu sobie doczytaj, albo i nie bo to raczej nie ma zastosowania w Twoim problemie.
   Zresztą, ja tu żadnego problemu nie widzę (jeszcze).

Ale nie sądzę abyś miał tak duże obciążenie, aby w ogóle się tym zajmować.
Dlaczego nie sądzę?
Ponieważ pytanie jest z gatunku coś tam wiem, ale nie mam doświadczenia.
Nikomu bez doświadczenia raczej nie daje się do zrobienia systemu z ekstremalnym obciążeniem.

czy dla każdego klienta stworzyć również własna tabelkę locales.? Ale jak to? Skoro masz takie pytania to zakładam, że staram się robić premature optimalization (polecam to: https://stackify.com/premature-optimization-evil/ ).

Jeśli boisz się o wydajność na tym etapie - to po prostu sprawdź wydajność, możesz przecież określi czas wykonania zapytania, możesz spreparować np kilka(naście/set) rekordów i badać zapytania.

Jeśli dopiero zaczynasz projektowanie - ofc warto zrobić to dobrze, ale wg mnie i Twojego opisu nie powinieneś się tym martwić teraz.