Antar att det inte finns något max antal tabeller man kan lägga i en databas, men finns det fördelar att dela upp tabellerna över flera databaser? Något som hör till praxis? Hur många tabeller har ni i en databas, ungefär?

Mig veterligen finns det ingen fördel rent prestandamässigt att dela upp tabeller på flera databaser. Den enda fördelen jag kan se är att man möjligtvis får en överskådligare struktur om man nu har väldigt mycket tabeller.

Har haft alltifrån 1 tabell till 80-100st per databas. Ibland på flera platformar som man jobbar mot parallelt/samtidigt i samma applikation. Då gäller det att man har ett bra databasschema över vad alla tabeller innehåller, deras struktur osv :P

Om man följer normaliseringsmetoden, så uppstår sällan behov efter extremt många tabeller. Jag säger sällan eftersom jag inte vet vad du vill lagra. Har du läst på om databasdesign så är du på bra väg.

Jag tror knappast att Mysql skulle prestera bättre genom att skapa tabellerna i olika databaser. Har du så extrema krav så kanske du ska tänka på en "riktig" databasmotor såsom Sybase och Oracle. Både med Sybase och Oracle kan du styra vilka "lagringsskluster" en viss tabell ska läggas på. Ett lagringskluster kan i sin tur ligga på separata diskar/arrayer för bättre prestanda.

/Zoran

Jag har över 1400 tabeller i en databas, och den klagar inte.. ;)

Har du några boktips?

Ja då har jag långt kvar... :)

Här är en kanonbra (verkligen) url från linköpings universitet som hänger ihop lite med databaskursen som går här:
http://www.ida.liu.se/~tompa/databaser/index.html

Har du några boktips?

Nej, men ännu bättre.

http://www.ida.liu.se/~tompa/databaser/

Det är en sida gjord av en mycket kompetent man. Jag tycker att den är lättförstålig och lätt att läsa.

Hmm, kan du inte berätta varför du har 1400 tabeller i en databas?

Det luktar dålig design, men det behöver inte vara så.

Låt mig förtydliga. Att manuellt skapa 1400 tabeller är ett ...vetes jobb. Förrutom om man inte använder skript. Använder man skript så antar jag att de flesta tabeller har samma typ av data. Har man samma typ av data i olika tabeller, så luktar det dålig design.

Så upplys mig gärna.

/Zoran

Åh, jo det var bra. Tack grazzy och zoran för länken.

Det är historiska kursdata för finansiella instrument, en tabell per instrument. Det är samma typ av data, tabeller skapas automatiskt. En post läggs till per dag. Har du förslag på annan design, välkommen att skriva! :)

EDIT: ett alternativ är förstås att ha en gigantisk tabell, med ett extra fält som är instrumentets namn. Tycker dock att detta skulle göra databasen väldigt svåröverskådlig och är tveksam om det är några prestandamässiga fördelar heller.

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

Det händer då och då, men är inte det minsta svårt. Jag byter namn på tabellen, med ett skript. I din modell byter jag instrumentnamn på en rad i tabellen (instrument, id). Lika enkelt förstås där. Smaksak.

Du får ursäkta, men jag tänker fortsätta göra på det sätt som är enklast för mig. :) Mitt inlägg här var aldrig någon fråga om att lösa ett problem, för det är inga problem. Det var bara en upplysning att det går utmärkt att ha många tabeller om det skulle behövas.