Helo.

Robie strone, na ktorej newsy beda w dwoch wersjach jezykowych - i teraz chce, aby przy dodawaniu do dwoch roznych tabel ten sam news polski i angielski mial to samo id w obu tabelach, tak zebym pozniej mogl go latwo edytowac/kasowac.

elo lolo
rozdziel na dwi tabele

newsy: id | data | autor | ... |

newsy_txt: id | newsy_id | txt_pl | txt_en | .... |

@ghostrider a po co rozdzielac? w jednej nie mozna trzymac wersji jezykowych??

tak jakoś to zrozumielem,

autor postu niepotrzebnie che sobie kompikowc zycie i robic dwie tablede a beda mialy to samo tylko w innych wersjach jezykowych wiec po co zrobic jedna tabele

news_id, czas, autor, tytyl_pl, tytul_en, tresc_pl, tresc_en i wsio

nie mozna projektowac tak, ze sie ma w tabeli pola textowe na kazda wersje jezykowa

najprostrzy przyklad to :

document_id, author, date

document_data_id, document_id, language_id, summary, content


kiedys to chyba projektowalem na 3 tabelach, ale nie mam tego przy sobie

@sf a dlaczego nie mozna?? bo jakos mnie nie przekonales

ok mozna zrobic tak jak napisales albo tak jak zaproponowal ghostrider ale po co komplikowac no chyba ze to czyms uzasadnisz swoje slowa

wychodze z zalozenia aby upraszczac rozwiazania a nie je kompikowac.

Skoro ma TYLKO 2 jezyki i NIE ZAMIERZA NIGDY wprowadzac wiekszej ich ilosci to mu wystarczy jedna tabela.

a ja wychodze z zalozeniai by nie pisac na pale pisze sie tak, aby latwo mozna bylo rozszerzac swoje programy... np. jesli dojdzie nowy jezyk to nie musisz grzebac w bazie, tylko z panela administracyjnego dodajesz sobie nowy jezyk, zostanie zapisany do tabeli np. languages i KONIEC, masz mozliwosc teraz we wszystkich miejscach panela administracyjnego dodawac, edytowac dokumenty w nowym jezyku, a sprobuj teraz dodac nowy jezyk wg Twoje sposobu... grzebanie w bazie, dodawanie jakis formularzy nowych, pisanie od nowa zapytan sql...

@dr_bonzo: a masz taka gwarancje? bo wg. mnie nigdy jej nie masz, nie raz sie przekonalem w pracy, ze zalozenia zalozeniami, a potem jak szef Ci powie, ze jednak zmieniamy plany to co? powiesz mu, przepraszam szefie, ale MIELISMY NIGDY NIE ZMIENIAC tych zalozen... sorry, ale to nie przejdzie

@sf: wyraznie zaznaczylem warunki dla jakich jedna tabela jest wystarczajaca, a ze sa trudne do spelnienia to juz inna sprawa

ok sf w takim przypadku moge sie zgodzic ale jesli aplikacja to nie jakis duzy projekt tylko ksiega gosci albo cos to wystarczy jedna tabela

co do edycji w jednej tabeli to tez nie bedzie to jakis koszmar kolumny mozna nazywac np "text_pl" czy "text_en" zazwyczak w sesji trzymasz wartosc jakiej wersji jezykowej uzywac np $_SESSION['lang'] = 'en'; wiec nie satanowi to problemu przy zapytaniach:
SELECT tytul_$lang, text_$lang FROM news

nie ma potrzeby stosowania zlaczen dla tabel co zawsze wplywa na wydajnosc

Dziwie sie ze piszecie o tym zeby w 2 tabelach umieszczac wersje jezykowe. MySQL radzi sobie dobrze z milionami rekordow a nie sadze ze az tyle tekstow bedzie w tej tabelce. Jesli celem serwisu bylo by zbieranie i trzymanie tekstow w wielu jezykach to i tak jest wygodniej trzymac to w 1 tabeli. Wiec nie ma sensu sobie komplikowac.

Dla mnie, to co powiedział sf jest bardzo ważne i nie widzę żadnych problemów by stosować taki układ bazy. Jeżeli ktoś nie widzi powodów by stosować takie standardy, to kiedyś je zobaczy
Pzdr.

Ja również optuję za rozwiązaniem opartym na 2 tabelach.

Jednak w innej konfiguracji.

1 tabela - dane wspólne dla newsa
id , autor, data, uprawnienia...

2 tabela - content

id, id_newsa, lang , text, title


Dlaczego tak?
Po pierwsze - argument już wymieniany - bardzo łatwa rozszerzalność.

2. A co wtedy gdy jakiś materiał nie ma określonych wersji językowych? Spradzanie czy pole jest puste i przechowywanie "pustych" pól w bazie? A gdzie tu normalizacja?
Powyższe rozwiązanie pozwala na banalnie łątwe zarządzanie tym, a także na podział odpowiedzialnośći za poszczególne wersja na różnych ludzi.