Visa ett inlägg
Oläst 2005-05-27, 14:50 #20
zorans avatar
zoran zoran är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Jun 2004
Inlägg: 598
zoran zoran är inte uppkopplad
Mycket flitig postare
zorans avatar
 
Reg.datum: Jun 2004
Inlägg: 598
Citat:
Ursprungligen postat av kullervo
Citat:
Originally posted by -aikon@May 26 2005, 18:06
Citat:
Ursprungligen postat av grazzy
I princip inte. Dina index måste vara korrekta dock.
Ja, det var väl en parentes det där med WHERE. Men som sagt överskådligheten. Det är en del manuellt pulande med datan, därför underlättar det mycket att ha en tabell för varje instrument, så man i phpmyadmin kan gå in och titta på viss data, utan att köra något sql-anrop varje gång.

Båda metoderna är ju egentligen lika överskådliga. I en viss applikation (såsom phpMyAdmin och förmodligen de flesta andra GUI) blir metoden med fler tabeller mer överskådlig som du säger, och om det underlättar mycket för dig så skulle åtminstonde jag köra så. Det är ju inte några riktiga nackdelar med att ha det på det viset.
Eller jo.

Så länge du kan "gissa" hur din tabell ska heta är det fint. Vad händer när "styrelsen" beslutar att en instrument foo ska heta foo_a eller liknande. Det kanske inte tillämpar just här, men i andra lägen. Man är i princip låst.

Har man en tabell där man lagrar ID, och sen attributen för det id-et, och sen data i en annan tabell som man knyter till ID-et i den första, gärna med foreign keys med "on update cascade on delete cascade", så kan du göra en ändring i datat helt transparant för din applikation.

Skulle man plötsligt få för sig att ändra nomenklaturen i första fallet måste du hacka om din applikation för att det ska fungera.

/Zoran
zoran är inte uppkopplad   Svara med citatSvara med citat