/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Store Tabeller Vs Flere Tabeller
Fra : Mark S. Rasmussen


Dato : 14-03-02 14:07

Hej alle. Jeg arbejder på et CMS system. Her kan folk oprette websites, og
tilføje sider osv. I øjeblikket har jeg f.eks en tabel som indeholder alle
sider, fra de forskellige kunder, hvor hver side har et customerID. Denne
tabel vil nok i løbet af rimeligt kort tid blive ret stor, derfor er mit
spørgsmål, om det er smartere af mig at lave en ny tabel til sider, til hver
kunde. Eller om jeg bare skal beholde denne ene store tabel, som indeholder
alle kunders sider. Grunden til jeg spørger, er at systemet gerne skulle
være fremtidssikret.

Mvh Mark

--
www.gameshots.dk - For seriøse gamere!
www.profiled.org - Vil du købe den?



 
 
Mikkel Bundgaard (14-03-2002)
Kommentar
Fra : Mikkel Bundgaard


Dato : 14-03-02 15:01

"Mark S. Rasmussen" <mark@tv.dk> wrote in message news:a6q78r$2b26$1@news.cybercity.dk...
> Hej alle. Jeg arbejder på et CMS system. Her kan folk oprette
> websites, og tilføje sider osv. I øjeblikket har jeg f.eks en tabel
> som indeholder alle sider, fra de forskellige kunder, hvor hver
> side har et customerID. Denne tabel vil nok i løbet af rimeligt
> kort tid blive ret stor, derfor er mit spørgsmål, om det er
> smartere af mig at lave en ny tabel til sider, til hver kunde. Eller
> om jeg bare skal beholde denne ene store tabel, som indeholder
> alle kunders sider. Grunden til jeg spørger, er at systemet gerne
> skulle være fremtidssikret.
>
> Mvh Mark
Hej Mark

Hvis database skal være fremtidssikret og "lettere" at ændre i
fremtiden, skal du normalisere den. Teknikker til normalisering
af databaser er beskrevet i de fleste introducerende databasebøger.
F.eks. An Introduction to Database Systems af C.J. Date eller
A First Course in Database Systems af Jeffrey D. Ullman og
Jennifer D. Widom. Kort fortalt får du sikkert flere små tabeller,
som er "knyttet" sammen.

For tutorials se evt. denne søgning på google.com
http://www.google.com/search?hl=da&ie=ISO-8859-1&oe=ISO-8859-1&q=introduction+database+normalization&lr=
--
Mikkel Bundgaard
IT University of Copenhagen
http://officehelp.gone.dk
Codito, Ergo Sum



Martin Christensen (15-03-2002)
Kommentar
Fra : Martin Christensen


Dato : 15-03-02 17:36

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Mark" == Mark S Rasmussen <mark@tv.dk> writes:
Mark> Jeg arbejder på et CMS system. Her kan folk oprette websites, og
Mark> tilføje sider osv. I øjeblikket har jeg f.eks en tabel som
Mark> indeholder alle sider, fra de forskellige kunder, hvor hver side
Mark> har et customerID. Denne tabel vil nok i løbet af rimeligt kort
Mark> tid blive ret stor, derfor er mit spørgsmål, om det er smartere
Mark> af mig at lave en ny tabel til sider, til hver kunde. Eller om
Mark> jeg bare skal beholde denne ene store tabel, som indeholder alle
Mark> kunders sider.

Det kommer an på hvordan du vil tilgå dine sider. I de fleste tilfælde
vil det nok ikke give mening at lade hver kunde have sin egen tabel.
Hvis jeg var dig ville jeg nok bruge to tabeller til sider: en med
information om siden og en med selve indholdet, hvor du joiner de to
på en side-ID. Derved kan du, hvis du er lidt smart, sørge for at have
fast rækkestørrelse i første tabel (giver hurtigere opslag i
tabellen), og med en side-ID som primær nøgle i anden tabel skulle du
kunne lave rimeligt effektive equijoins. Eksempel:

page_info page_content
_________________________... ___________________
| CustID | PageID | URI | ...| | PageID | Contents |
|--------|--------|-----|-...| |--------|----------|
.. . . . . . . .

Den første tabel er lidt kringlet, da man for at få en fast
rækkestørrelse skal have et fast antal characters for URI'en (med
mindre, selvfølgeligt, du bruger server-side scripting, hvor den ikke
behøves i databasen; denne løsning ville jeg selv bruge hvor muligt),
og så skal du finde en rimelig maksimal længde for dem. Nå ja, opret
tabellerne med

CREATE TABLE page_content (
PageID int PRIMARY KEY,
Contents text
);

CREATE TALBE page_info (
CustID int,
PageID int REFERENCES page_content,
URI varchar(n) PRIMARY KEY,
...
);

I første statement kan datatypen 'text' erstattes med det, der virker
for din DBMS.

Nogle DMBS'er håndterer variable tekststrenge uden maksimal længde på
den måde, at de ikke gemmes på disken sammen med resten af rækken, men
der gemmes blot en pointer til det reelle indhold. Jeg mener at
PostgreSQL gør det på denne måde. I så fald er det omsonst at bruge to
tabeller, da DBMS'en allede gør det, du ønsker.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAjySIuEACgkQYu1fMmOQldXuaACfZqQYBkc8QYPgNk5m6YlR1J6J
vbEAnj5UlVoAMPEXT2C9LPbdzMni3s6D
=2HFY
-----END PGP SIGNATURE-----

Søg
Reklame
Statistik
Spørgsmål : 177501
Tips : 31968
Nyheder : 719565
Indlæg : 6408527
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste