[database] Dynamische lengte *

[Verwijderd]

Ik ben op dit moment bezig met het ontwikkelen van een pakket waarin de beheerder van het pakket een record met velden aan kan maken welke ingevuld moeten worden. Een veld die bij een record hoort heeft bepaalde eigenschappen waaronder hoeveel karaketers er bijvoorbeeld in het veld kunnen staan. Echter wil ik hier geen directe beperking aangeven maar wel de snelheid erin houden.

Zelf zat ik er aan te denken om diverse tabellen te maken met diverse karakterlengtes aan gekoppeld.

code:

Table char8
id (integer, primary key/idx)
value (char, 8 karakters)

Table char16
id (integer, primary key/idx)
value (char, 16 karakters)

enzovoorts tot dat het niet meer efficient is 
en dan overgaan op een evt text of die lengte 
als maximum aanhouden waarbij het niet meer 
efficient is

Deze tabellen zullen uiteindelijk met een relatie tabel bij een bepaald record horen. Zou dit nadelinge gevolgen kunnen hebben, het lijkt me dat een index op basis van integers vrij snel moet zijn echter hoe pakt het uit in de praktijk wanneer er extreem gebruik van gemaakt.

En zie ik wat over het hoofd? zijn er betere manieren om dit probleem aan te pakken?

[faabman]

eigenlijk snap ik geen bal van hetgeen je bedoelt, maar, als je een app aan het maken bent waarmee tabellen worden samengesteld, laat de gebruikers dan informatie opgeven die JIJ verwerkt in een sql string waarmee je een tabel maakt in de database...

[Verwijderd]

ik heb gemerkt dat het aanmaken van tabellen in een database funest wordt op den duur, en voor de eerste intentie gaat het om weinig tabellen die dan zouden worden aangemaakt, maar in een later stadium kan het om 10 tot 100-vouden gaan

wat ik bedoel is vrij simpel:
om te voorkomen dat ik een tabel aanmaak waarin de waarde van een veld beperkt is aan bijvoorbeeld 100 karakters en ik niet kan zeggen bij welk veld zoveel karakters moet komen kijken wil ik dit flexibel maken. Altijd is er een beperking, dat realiser ik me ook, echter er zullen vast middelen zijn om effectief te werk te gaan ipv allemaal velden van het type TEXT aan te maken in de database.

[ Voor 48% gewijzigd door Verwijderd op 27-11-2003 20:13 ]

[djluc]

Ik kan me allereerst niet voorstellen dat het sneller is om te joinen in plaats van té grote velden kiezen. Dan is een join altijd langzamer inderdaad. Wat je eventueel zou kunnen doen is voor 2 tabellen gaan, maar zelfs dat is waarschijnlijk de extra hoeveelheid programmeren nog niet eens waard. Voor het verschil tussen 8 en 16 al helemaal niet.

Misschien kun je wat meer info geven over het aantal verwachte inserts, selects en de hoeveelheid gegevens, en dan met name de grootte er van?

Heel veel tabellen aanmaken lijkt mij in ieders geval niet de oplossing..

[ Voor 8% gewijzigd door djluc op 27-11-2003 20:32 ]

[Verwijderd]

als ik een tabel die aangemaakt wordt door een beheerder omschrijf als een virtueel tabel dan gaat het om

25 van deze tabellen
waarbij de insert gemiddeld zullen liggen op 5000 inserts

selects zal steeds meer toenemen maar in het begin 10 x per uur

de grootte hangt dus af van de wensen van de beheerder maar het zal voornamelijk om registratie van naw + daarbij verschillende diverse dingen zoals voor iemand die een invulling in de vorm van een tracking programma wil maken velden als prioriteit enz...

[Grijze Vos]

Geef eens een iets duidelijkere omschrijving van hetgeen je wilt realiseren. Want met wat vage getallen roepen kunnen wij niets. Geef concreet aan wat je in je tabel wilt proppen, welk DB-pakket je gebruikt, etc...

[ACM]

Je wilt per veldtype een aparte tabel en dat aan een "echte tabel" koppelen dmv de keys?

Dat is geloof ik een variant op de sterkste vorm normaliseren, maar je verliest wel de doelstelling van het normaliseren een beetje uit het hoofd en je maakt een enorme fout:
De fout is namelijk dat je velden van verschillende tabellen in dezelfde "veld-tabellen" gaat steken, terwijl die velden helemaal niet bij elkaar horen.

Over het algemeen is het aanbevolen gewoon tabellen te maken voor wat je nodig hebt en niet te klooien met allerlei oplossingen die handig lijken, maar, ik gok in dit geval, niet zijn.

Als je over performance begint te praten voor je ontwerp af is ben je sowieso al fout bezig, ontwerp eerst de boel goed en ga dan over de performance praten...
Ow en zoek een goed boek/stuk tekst over normaliseren

Owja, verder ook van mij: leg het eens duidelijker uit

[ Voor 4% gewijzigd door ACM op 28-11-2003 00:30 ]

[Verwijderd]

Ok ok

From scratch:

Ik heb een tabel met relatiegegevens. Naast deze gegevens wil ik de gebruiker de mogelijkheid bieden om velden toe te voegen. Aangezien ik dit zo simpel mogelijk voor de gebruiker wil houden, biedt ik een aantal mogelijkheden (html input elementen, checkbox, etc) en wil niet dat de gebruiker snel tegen een limiet aanloopt.

Daarom vraag ik me af hoe ik het beste kan regelen om iets tegen limieten te doen want ik wil niet dat er informatie "naast" valt door een beperking van het aantal karakters dat ingevoerd kan worden.

dus
opmerking[50]
en er wordt
een waarde ingevoerd met 70 karakters, dan wil ik niet dat de gebruiker een foutmelding krijgt maar ik wil ook niet dat er "20 naast vallen"

[Cavorka]

Maar je wilt dus dat telkens de grootte van elk veld aangepast word op het moment dat er iemand iets invult dat langer is dan de op dit moment ingestelde grootte?

een waarde ingevoerd met 70 karakters, dan wil ik niet dat de gebruiker een foutmelding krijgt maar ik wil ook niet dat er "20 naast vallen"

Tsja... lijkt me een soort tegenspraak: er gaat dus eigenlijk iets mis (te grootte invoer), maar dit wil je niet doorgeven aan de gebruiken. Fair enough, maar waarom dan niet gewoon een text field van maken? Hoeveel miljard records ga je krijgen dat je dit niet wilt doen?

TEXT Tekstveld zonder een maximale grootte (handig voor grote documenten)

[ Voor 9% gewijzigd door Cavorka op 28-11-2003 15:01 ]

[Swerfer]

Waarom geen varchar(x) gebruiken? X kan dan dacht ik maximaal 8000 zijn. Dus de database blijft klein, als je maar 100 tekens invoert worden er ook maar 100 opgeslagen, terwijl de database relatief weinig trager wordt...

[ACM]

Verwijderd schreef op 28 november 2003 @ 14:54:
Ik heb een tabel met relatiegegevens. Naast deze gegevens wil ik de gebruiker de mogelijkheid bieden om velden toe te voegen.

Is dat eenmalig zo voor een enkele gebruiker (dus per database 1 gebruiker die dat wil) of is dat voor veel gebruikers of iets dat ze vaak zullen wijzigen?

Aangezien ik dit zo simpel mogelijk voor de gebruiker wil houden, biedt ik een aantal mogelijkheden (html input elementen, checkbox, etc) en wil niet dat de gebruiker snel tegen een limiet aanloopt.

Waarschijnlijk is je oplossing wel redelijk handig, maar kan het iets mooier.

Daarom vraag ik me af hoe ik het beste kan regelen om iets tegen limieten te doen want ik wil niet dat er informatie "naast" valt door een beperking van het aantal karakters dat ingevoerd kan worden.

Als er gedefinieerd is dat het max 50 chars is, dan moet je dat ook gewoon afdwingen en niet gaan klooien met allerlei rare dingen waardoor je toch geen limiet afdwingt, imho

Ik zou zelf denk ik zoiets als databasemodel maken:
specialegegevens: sgid integer, gnaam varchar(60), veldspecificaties, etc
veldinvulling: sgid integer, gebruikersid integer, invulling varchar(2048) oid of text

waarbij de onderstreepte velden de primary keys zijn en de schuingedrukte foreign keys
Een varchar is een tekstveld waar de opslag afhangt van de data, niet van de veldspecificatie zoals bij char. En je moet in je software zelf dan afhandelen wat er gebeurt als iemand een te grote waarde opgeeft (wat je imho dus wel degelijk moet afhandelen en vermelden).

[Verwijderd]

Natuurlijk is het zo dat er altijd wel een limiet moet zijn, echter ik weet zelf dat de gebruikers die met relatiebeheer pakketten werken meer zeiken op het pakket vanwege beperkingen en velden die te klein zijn dan dat ze over de snelheid praten. (echter ik vind snelheid zelf wel heel belangrijk)

Ik heb even een snel testje gedaan met een char en een varchar en wat dat betreft is varchar all what I need. Wellicht wat trager in sommige gevallen maar snel genoeg.

[ACM]

't Is hooguit trager omdat de velden een dynamische ipv vaste grootte kunnen hebben, maar in de meeste gevallen is het verschil met een char-veld nihil

[ Voor 4% gewijzigd door ACM op 28-11-2003 17:38 ]