Nå zoran, du frågade. Dålig design eller ej?

Skulle säga att det är lite dålig design ja. Varför inte ha en tabell där du har namnen för instrumenten sen har du bara ett fält i din tabell med all infon som pekar till rätt instrument för att få fram namnet osv.

Det tycker jag iaf låter mer överskådligt än att ha 1000+ tabeller.

Jag förstår inte riktigt hur du menar. Mina tabeller ser alltså ut så här ungefär:
Datum Högst Lägst Stängningskurs Omsättning

Instrumentets (oftast aktiens) namn finns i tabellens namn. Varje post är kursdata för en dag, från 1995 till idag.

Hur lägger jag upp det på något bättre och fortfarande överskådligt sätt?

Jag har även några tabeller med annan typ av data, där instrumentnamnet ligger i ett fält. Men där finns inte tidsdimensionen.

Två tabeller,
instrument {id, namn}
data {instrument_id, resten_av_datan, ..., ... etc }

Jag kanske har missat nåt viktigt här dock?

OK, det är i princip min alternativa lösning som jag skrev ovan, bara att instrumentnamnet lyfts ut och ersatts av ett id. Min invändning mot det är att det blir svåröverskådligt att ha alla 1000+ instrument för alla datum mellan 1995 och idag i en enda gigantisk tabell. Blir det inte också mer ineffektivt att behöva ha en WHERE i varje SELECT för att sortera ut rätt instrument, i stället för att som nu göra select direkt på en mindre tabell?

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.

Generellt sett, definitivt. Den bryter klart mot normaliseringsmetoden. Samma typ av data ska finnas i samma tabell.

Egentligen är det kanske tillsynes överskådligt. Men tabellnamnen måste hårdkodas i applikationen eller någon algoritm, för att beräkna tabellnamnen, skapas. Det kanske fungerar jättebra idag, men imorgon när du behöver ändra något är det plötsligt mycket svårare. Ditt skript eller du själv måste hålla reda på olika tabellnamn/instrumet. Dvs. du eller ditt skript gör det jobbet som databasmotorn är designad för.

Jag vet inte riktigt varför du tycker att det är jobbigt att lägga in en "where id=x" i dina querys.

Sen vet jag inte hur du kan tycka att det är överskådligt att "show tables" i mysql returnerar 1400 rader.

Om du dessutom råkar ha en rad data i varje tabell så har du ökat din datalagring med sisodär 200-300%, eftersom för varje rad data måste du lagra info om fälten som egentligen skulle kunna delas av alla tabeller.

Hursomhelst, den bästa metoden NI kan använda är ju naturligtvis den metoden som fungerar för er och den metoden ni har arbetsprocesser för. Objektivt sett är ni ute och cyklar en smula.

/Zoran

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