Witajcie,

Tworze amatorski (lecz nie oznacza to że ma nie być wykonany poprawnie) serwis/portal internetowy

Docelowo ma zawierać forum, bloga, aktualności, jakąś bazę z publicznymi rekordami (na potrzeby przykładu encyklopedia) oraz giełdę (powiedzmy sklep)
Chciałbym dodać tłumaczenia na wiele języków i wybór języka w zależności od kraju, wszystko w jednej domenie.

Oczywiście wszystkie przyciski, menu itd chciałbym dodać do bazy danych i sprawić aby była baza danych dla wielu krajów.

Pytania są następujące:
1) Czy stworzyć jedną bazę danych dla wszystkich krajów czy dla każdej wersji językowej każdego kraju stworzyć osobną bazę danych?
2) Gdzie szukać sprawdzonych informacji na ten temat? (książki, poradniki, fora, gotowe przykłady takich baz)?
3) Czy wybór MySQL do takiego projektu jest poprawny?
4) Czy lepiej stworzyć plik językowy ze zmiennymi czy odpytania bazy danych?
5) Które rozwiązanie pliki czy baza danych będzie szybsze i jak to efektywnie sprawdzać i co jest do tego potrzebne?

Uprzedzając pytanie: treść będzie w zasadzie taka sama lecz tylko przetłumaczona tz. np. jeden rekord będzie miał znaczenie takie samo lecz będzie przetłumaczony na kilka języków.

Baza musi być jednolita tz. jeżeli nie ma tłumaczenia domyślnie rekord wyświetla się w określonym z góry języku, lecz to będzie się raczej nie często zdarzać.


Proszę o wypowiedź osoby które miały z tym styczność.

Tak na dobrą sprawę nie ma znaczenia jak to zapiszesz bo prawidłowa usługa translatora może tłumaczyć dowolne ciągi znaków (np. na bazie plików .po). Wtedy dana fraza z bazy czy na stronie jest i tak automatem tłumaczona po kluczu który jest treścią w pierwotnym języku.
PS. Wybór mysql nigdy nie jest poprawny ze względu na braki, nieścisłości, niełatane latami bugi

Nie jest to usługa translatora (nie będę wykorzystywał translatora) wszystkie pola do języków ustawione zostaną statycznie.

Co proponujesz jako alternatywę MySQL? Można listę tych bugów i nie łatanych latami dziur? Czego będzie brakować w MySQL a co znajdę w innym rozwiązaniu?

P.S. prosiłem o literaturę, przykłady i rozwiązania tego typu.

Z darmowych oczywiście PostgreSQL.

Podasz źródło które porównuje pozytywnie MySQL/Psotgree SQL lub opiszesz dlaczego postgree SQL jest wg. Ciebie lepszym wyborem?

Jest naprawdę pełno opracowań.
Są dwie wersje czyli zwykły Mysql i MariaDb. W zależności od czego trafisz na serwerze spotkasz różne bugi. Coś może być w jednym połatane, w drugim nie. Tak czy inaczej są mało zgodne ze standardami np najbardziej oczywiste pole daty i ISO8601. Zobacz co zwraca mysql a co inne silniki. W postgresie procedury możesz pisać w wielu językach w tym również PHP i są dużo bardziej zaawansowane. W Mysql są bardzo ograniczone wyzwalacze. Można tylko jedno zdarzenie przypiąć. Postgres posiada wiele przydatnych typów danych w tym tablicowe i JSON. Ma rozszerzenia np możesz dodać słowniki do wyszukiwania pełnotekstowego. Już nie mówiąc o tak podstawowych rzeczach jak checki (check constraint). Itd itp.

Jak odniesiesz się do faktu iż mysql jest dużo wyżej w rankingach popularności niż PostgreSQL
Nie wiem czy wlicza się w to EnterpriceDB

Bo zawsze ciężej było go skonfigurować, trzeba oskryptować żeby rozdzielić uprawnienia. Większość hostingów to automat gdzie nawet konfiguracja PHP nie nadaje się do użytku produkcyjnego (już widziałem takie gdzie była jakaś baza zainstalowana a brakowało rozszerzenia do jej obsługi). Ale zmienia się to ostatnio i większość porządnych firm oferuje też Postgresa, w mniejszych najczęściej za dodatkową opłatą.

A też zupełnie inny poziom startu jest co się niestety później odbija na wiedzy. Jest trudniejszy. W pracy robiłem kilka razy rekrutację i bazy danych generalnie leżą. Ludzie wychowani na mysql nie znają podstaw. Nie potrafią odpowiedzieć na pytania co to klucze obce, wyzwalacze, procedury, jak działają indeksy. Potrafią stworzyć tabelkę i jakieś proste zapytania ale wiedza na tym się wyczerpuje.

Ci sami ludzie jakby pracowali na postresql tez by tego nie wiedzieli. Twoje posty zwalaja lenistwo ludzi na mysql co jest totalna bzdura. Wszystko to co tu napisales rowniez istnieje w mysql i nie rob prosze z tej bazy jakiegos potwora. Fakt, jest latwiej, co nie zmienia faktu ze istnieje i dziala calkiem sprawnie.

@ziemniak jestem pewien ze dla Twojego projektu mysql bedzie rownie dobry co postgresql. Rownie dobrze jeden projekt mozesz zrobic na mysql, inny na postgresql i sam ocenisz co dla ciebie jest lepsze.


Oczywiscie ze jedna baza danych, po co sobie na sile komplikowac zycie.

Oczywiście że przez lata technologie się zmieniły i stos LAMP nie jest już niczym niezwykłym a wręcz przestarzałym. Oprogramowanie poszło do przodu, inaczej się pisze kod niż za czasów PHP4. Jednak Mysql tkwi dalej w przeszłości, posiada bugi niezałatane od ponad 10 lat. A gdzie masz np. ograniczenie sprawdzające skoro piszesz że wszystko istnieje w mysql (i nie mówię o symulowaniu triggerem albo innych kombinacjach)? Dodano chociaż obsługę JSON ale dalej mocno cząstkowe i niedopracowane. A i tak większość hostingów ma v5.5 albo 5.6. A spójrz na rozwój Postgresa między np 9.1 a 9.5.
Na innych SBD korzystanie z zaawansowanych funkcji jest rzeczą całkowicie naturalną i nawet w trakcie nauki (tutoriale, kursy czy szkoła) po prostu się z nich korzysta i opisuje. Dlatego jak ktoś wychodzi ze światka Mysql zaczyna inaczej patrzeć na sam SQL (oczywiście jeśli nie jest leniem). To lenistwo też po części wynika z tego że nikomu nie chce się pisać wyzwalaczy czy wirtualnych kolumn żeby łatać dziury. Ale też nie jest możliwe ich wykonanie dla nie SUPER usera (uprawnienia + binary logging dla wyzwalaczy i procedur).

Wystarczy mi MYSQL gdyż projekt jest czysto internetowy, później może dorobię wersję lub aplikacje mobilne.

NoSpor - dzięki za w moim odczuciu bardziej rzeczową wypowiedź, chyba dużo siedzisz w programowaniu tego typu rzeczy.
Mógłbyś mi polecić jakieś źródła na temat tworzenia takich wielo-językowych baz danych?

To zależy od potrzeby, ilości danych itd.

Jedno z rozwiązań zakłada utworzenie 1 tabeli podstawowej np. products, i 1 dodatkowej np. product_translations z kolumnami: ID, lang, description, title, short_desc itd.
Do tego klucz kombinowany na (ID, lang) co by nie powtarzać danych.

Rozwiązanie sprawdza się dość dobrze. Ale powstanie np. problem z fallback (chyba że zawsze jako pierwsze tłumaczenie będzie w bazowym języku).

Tłumaczenia statyków również możesz oprzeć o strukturę: trans_key, lang, translation
Do tego możesz śmiało cache wpakować.

Innym rozwiązaniem są statyczne pliki np. PO (https://en.wikipedia.org/wiki/Gettext)

Rozwiązań multum