[database]leidt veel tabellen tot veel dataverkeer

[Verwijderd]

vraagje... is het verstandig om in je database meer dan 100 kollomen aan te maken? dus dat elke regel in de database 100 kollomen heeft? ( wordt het uitlezen hier door traag? ) en trekt dit veel dataverkeer

[Verwijderd]

Dat hangt er van af waarvoor je het nodig hebt, er is haast geen situatie te bedenken waarvoor je 100 kolommen nodig hebt. En met dataverkeer heeft dit werkelijk niks te maken.

[Kwistnix]

Lijkt me niet echt een probleem.

[TweakBoy]

vraagje... is het verstandig om in je database meer dan 100 kollomen aan te maken? dus dat elke regel in de database 100 kollomen heeft?

Je moet dat zelf weten, maar is het wel nodig om dat zo te doen? beter is het in meerdere tabellen te doen. Ligt aan het DBRMS dat je gebruikt... in principe krijg je veel problemen als je die dingen gaat updaten..

( wordt het uitlezen hier door traag? ) en trekt dit veel dataverkeer

doh, deze kun je zelf wel een antwoord opgeven...
DATABASE REQUESTEN zijn SERVERSIDE, dus worden niet meegerekend in je dataverkeer
Tenzij je al je data helemaal in een pagina dumpt

[Verwijderd]

Op zaterdag 29 juni 2002 16:47 schreef TweakBoy het volgende:

[..]
doh, deze kun je zelf wel een antwoord opgeven...
DATABASE REQUESTEN zijn SERVERSIDE, dus worden niet meegerekend in je dataverkeer
[..]

tenzij je databaseserver niet bij je hostingprovider staat

[TweakBoy]

Op zaterdag 29 juni 2002 16:55 schreef woeitje het volgende:

[..]

tenzij je databaseserver niet bij je hostingprovider staat

dat wordt toch niet gelogd in de apache logfiles?
mijn hoster telt alleen de dataverkeer in de apache http en ftp logfiles.... (Plesk dus)

[Verwijderd]

Maar ja met 100 kolommen ben je niet echt slim bezig denk ik, dat is gewoon vragen om moeilijkheden. je maakt het jezelf uitermate moeilijk met het maken van de tabel en het inserten en updaten enz. En het kan bijna niet anders of je krijg een enorme overhead aan gegevens in de tabel en een enorme hoeveelheid aan vieze data. Tabellen met zoveel kolommen zijn alleen handig in het geval van datawarehousing.

[Verwijderd]

En over dat dataverkeer verhaal, tja het ligt er aan wat jij er mee wilt doen, is dat het voor een website die op dezelfde server draait, plaats je de gehele tabel in een keer op het scherm, of is het voor een db apllicatie.

[PowerSp00n]

Op zaterdag 29 juni 2002 16:56 schreef TweakBoy het volgende:

[..]

dat wordt toch niet gelogd in de apache logfiles?
mijn hoster telt alleen de dataverkeer in de apache http en ftp logfiles.... (Plesk dus)

Die van jou wel ja. Maar andere waarschijnlijk niet.

[Verwijderd]

Vertel eens waar je 100 kolommen voor nodig hebt?

Ik kan me niet indenken, dat je dat nodig hebt.

[TheDane]

ik begin ook wel nieuwsgierig te worden

en zelfs in datawarehouse systemen kom je niet aan 100 kolommen denk ik .. gebruik dan liever views oid

en NEE, dan heb ik het niet over van die views-niet-ondersteunende dbms'en zoals mysql oid (mysql vanaf versie 5 overigens )

[Delphi32]

Op zaterdag 29 juni 2002 22:24 schreef ridde100 het volgende:
Vertel eens waar je 100 kolommen voor nodig hebt?

Ik kan me niet indenken, dat je dat nodig hebt.

Ik heb ooit eens moeten interfacen naar een DBMS waarin 1493 tabellen zaten met een totaal van ruim 36000 (!) kolommen. Dat is gemiddeld 24 kolommen per tabel, maar het systeem zat zo in elkaar dat er zeg maar 1200 tabellen waren met 2 kolommen, en 300 tabellen met gemiddeld 114 kolommen. Het komt dus voor.

Maar ik ga dat dus afraden. Je database dictionary wordt zo onleesbaar en ononderhoudbaar dat jij of je opvolger binnen de kortste keren de weg kwijt bent. Hou bij elkaar wat bij elkaar hoort, normaliseer in ieder geval tot de vierde normaalvorm, en het lijkt me heel stug dat je dan op tabellen komt van 25+ kolommen.

[Dash2in1]

Over het algemeen, nee, da's niet verstandig.

[Varienaja]

Ach.. als je select ding1, ding2, ding3 from tabel_met_1000_kolommen doet, dan worden er maar 3 kolommen verstuurd, dus dat dataverkeer is niet meer dan bij een 'smalle' tabel.

bij * Varienaja op het bedrijf hebben we tabellen met 150 kolommen. Zou misschien beter kunnen, maar je kent het: 1 wijziging in het datamodel, en je kan 100 applicaties gaan wijzigen.

[Vigory]

Het schijnt dat over het algemeen 1 tabel van 100 kolommen beter performed als dat het genormaliseerd is in meerdere tabellen.

Maar zoals ieder een zegt: je moet dit niet willen i.v.m. onderhoudbaarheid, overzichtelijkheid enz.

[LauPro]

Ligt er eigenlijk aan hoe je die kolommen noemt. Voorbeeld:

code:

       | Niveau1 | Niveau2 | Niveau3 | Niveau4 | Niveau5
----------------------------------------------------------
Piet     |   ja    |   ja    |   ja    |   nee   |  nee
Kees     |   ja    |   ja    |   nee   |   nee   |  nee
Jan |   ja    |   ja    |   ja    |   ja    |  ja 
Klaas    |   ja    |   nee   |   nee   |   nee   |  nee

Volgens mij ben je dan niet effciënt bezig
funnygames, kan je uitleggen waarvoor je dat nodig hebt? In dit geval kan je dus beter 1 kolom 'Niveau' aanmaken.

[ACM]

Op zondag 30 juni 2002 11:24 schreef Vigory het volgende:
Het schijnt dat over het algemeen 1 tabel van 100 kolommen beter performed als dat het genormaliseerd is in meerdere tabellen.

Dat hangt er ook heel sterk vanaf hoeveel je eruit nodig hebt.

Als je elke keer alle 100 kolommen nodig hebt kan ik me voorstellen dat dat sneller is.
Met elke keer 1 kolom zal het absoluut niet sneller zijn.

Mocht je willen zoeken in je 100 kolommen, dan krijg je allerlei prachtige OR's van 100 kolommen breed en is je performance VER te zoeken (aangezien je er ook nauwelijks op kan indiceren op zo'n manier).