Tworzę bazę danych dla tłumaczeń strony, każdy użytkownik będzie mógł zrobić sobie właśnie tłumaczenie. Każdy tekst do tłumaczenia, dla każdego uzytkownika będzie przechowywany jako osobny rekord.

[tabela tlumaczenia]
id - numer id
uzytkownik - numer uzytkownika, do ktorego nalezy dane tlumaczenie
nazwa - numer/nazwa tlumaczonego tekstu
tlumaczenie - tlumaczenie

i mam pytanie odnośnie pola ID, czy ono jest w ogole potrzebne tutaj?? z konstrukcji można wywnioskować że żaden rekord nie będzie się powtarzał ponieważ dla każdego użytkownika będzie pare róznych tekstów do tlumaczenia, tak więc wykluczona jest możliwość zbędnych powtorzeń. tak więc pole id chyba nie ma tutaj zadnego zastosowania

A teraz pytanie czy to pole id, w ogole przyśpieszy czy też sporolni taką tabelę, a chciałbym zaznaczyc że mogą być w niej dziesiątki tysięcy rekordów

dzięki za pomoc

id zbędne.
indexuj wg pola 'nazwa'

no a indexowanie jest konieczne?? bo wartosci dla pol nazwa będę takie same dla kazdego uzytnownika

Gdzie cos takiego wyczytales? Widze ze teoria sie klania, primary key zawsze jest potrzebny. Na postawie tego identyfikujesz rekord, przyspiesz zlaczenia tabel, jesli uzyjesz podselektow to wtedy zobaczysz roznice.

Indeksy stosuj gdy pola powtarzaja sie max 20 %, ale to i tak zalezy od specyfikacji, potrzebne do relacji i tam gdzie uzywasz warunkow.

Tak, ale nie zawsze jest potrzebny sztuczny klucz glowny, na tej tabeli mozna zalozyc PK na pola nazwa oraz uzytkownik i bedzie to dobry klucz glowny. To apropo teorii... Ja mimo wszystko wole zawsze dodawac sztuczny klucz glowny, bo ulatwia to wszelkie operacje typu usuwanie/edycja. Rekord identyfikujemy na podstawie jego PK, wiec w przypadku braku sztucznego PK, musimy przesylac do takich operacji wartosci wszystkich pol znajdujacych sie w PK (przy sztucznym mamy tylko jedna wartosc).

@FiDO Z wieksza czescia sie zgadzam, z tymi sztucznymi kluczami przemysl taka sytuacja nagle wyniki sa z podselekta i lepiej jest zwrocic id niz varchary lub longi kluczy podstawowych. Dla pewnosci tak jak ty pisalem zawsze stosuje primary key i jest to pole id.

Dlatego wlasnie napisalem, ze to jest teoria.. sztuczne PK wcale nie sa wymagane, ale ulatwiaja zycie, wiec lepiej je stosowac nawet jesli beda to nadwyzkowe dane.

tak więc co mi polecacie w tym przypadku?? bo jeżeli chodzi o użycie tego pola id w moich skryptach, to nie bardzo będę z niego kozystał, jedynie uzytkownik i nazwa, do deklarowania rekordu. tak więc jak??

Ja sięprzychylam do opini większości i polecam ci te id. Prędzej czy później ci się przyda, nawet jeśli teraz z tego sobie nie zdajesz sprawy

pozdro

jedno jest pewne! na pewno się nie przyda:P teraz rozchodzi się o to czy to ma przyśpieszyć czy spowolnić prace tabeli, bo ja bym chyba nie dawał tego id, skoro nie potrzebne, no ale sie nie znam, tak więc chcę waszego zdania
dzięki

jezeli moge wtracic swoje trzy grosze to zgadzam sie z opinia wiekszosci ze id sztuczne sie po pierwsze przydaje - zwlaszcza przy tabelach planowanych na co najmniej kilka tysiecy rekordow.... a pomysl z nadaniem pk na pole nazwa niestety jest fatalny w skutkach, gdyz pk zachowuje sie jak unique i nie bedziesz mogl dac dwoch takich samych nazw... a pozostawienie tabeli bez pk przy wiekszej ilosci rekordow poprostu sie nie oplaca z punktu widzenia czasu jaki beda zajmowac zapytania

no ale jakie zapytania, zawsze bede mial sprecyzowane wartosci uzytkownik i nazwa, a z id nie bede kozystal, na pewno nigdy! no bo nie mam jak. to moze lepiej teraz zapytam nie czy id jest potrzebne ale czy klucz w tabeli jest potrzebny i jaki by w tym przypadku ustawic??

ps. ja nie chce tego pola id robic bo wiekrzość ma w nawyku robienie go, itp. tak tylko dla picu

ale wlasciwie doszedlem do wniosku ze jest w ogole nie potrzebne, teraz jak z tym kluczem??

no dobra ale po cos Ci ta baza jest no nie?! wiec bedziesz robil "zapytania" do bazy chcący pobrac tlumaczenie prawda? wiec na tym rzecz polega, ze jezeli bedziesz mial duuuuuzo rekordow to klucz Ci sie przyda jak nic bo bedziesz szybciej otrzymywal wartosci z tabeli.... ale jezeli np. pole nazwa bedzie posiadalo unikalne wartosci (nie powatarzajace sie) to mozesz nadac pk na to wlasnie pole!!! a jezeli chodzi o klucze - to jezeli masz kilka tabel i beda jakos one od siebie zalezne to warto sie zastanowic nad dodaniem relacji

wszystko przemawia za id i na tym polu primary key. Ale od Ciebie i tak zalezy jak to rozwiazesz. Opinie innych znasz.