[SQL SERVER] Maximale record lengte ?

[Togt]

Beste tweakers,
Ik hoorde van de DB'er hier dat de tabel die we nodig hebben in onze applicatie niet past binnen SQL server. Mijn vraag aan jullie:

Ik heb een tabel waar ruw geschat een 1000 records per maand bijkomen. Ik heb 1 key, en wel ongeveer een 100 kolommen.

De DB'er vertelde me dat de maximale record lengte voor SQL server maximaal ong. 1900 tekens aan kan.

Hoe kan een professioneel DB nou zo'n restrictie hebben?
We hebben nu 5 verschillende tabellen met de velden opgesplitst gemaakt. Is dit dan de oplossing?
Is er een programma zoals TOAD voor Oracle maar dan voor SQL server?

[Verwijderd]

't Heeft ook te maken met de maximale lengte die een query mag hebben.

De oplossing: stukken query aan elkaar plakken.

[justmental]

Gegoogled:
http://www.swynk.com/friends/Vartanyan/Access_vs_SQLServer.asp
8000 bytes per rij.
1000 kolommen max in een tabel.

[ACM]

100 kolommen is idd nogal veel voor een tabel.

Kijk of je dat netjes over meerdere tabellen kan spreiden.

[Togt]

Hartelijk dank voor het snelle antwoord.
[RANT]
Ongelooflijk dat een product als SQL server het op de zakelijke markt redt!

- Case Sensitive
- Syntax die op zijn minst gezegd primitief is.
- Datum formatering is idioot!!!!
[/RANT]

Ik weet dat de 100 fields veel zijn, maar dit is een pure temp-tabel: Veel velden worden niet gevuld, het wordt weinig gebruikt etc. etc.

[Verwijderd]

Zo kan je lange queries (>8000 chars) maken in SQL Server (& MDAC-driven stuff): http://support.microsoft.com/default.aspx?scid=kb;EN-US;q286370

En een intelligent database ontwerp kan ook wonderen doen. (Dus niet zoiets van: ID, naam, zoekwaarde1, zoekwaarde2, zoekwaarde3, zoekwaarde4, etc)

[RANT]
Heb je Exact Synergy es aan de gang gezien? 100% SQL server optimized; probeer daar es aan te tippen! (Wanneer je 't in handen krijgt)
[/over RANT]

[chem]

ben ik toch benieuwd waarom je een key over 100 kolommen nodig hebt

[raptorix]

Op donderdag 07 maart 2002 11:53 schreef Togt het volgende:
Hartelijk dank voor het snelle antwoord.
[RANT]
Ongelooflijk dat een product als SQL server het op de zakelijke markt redt!

- Case Sensitive
- Syntax die op zijn minst gezegd primitief is.
- Datum formatering is idioot!!!!
[/RANT]

Ik weet dat de 100 fields veel zijn, maar dit is een pure temp-tabel: Veel velden worden niet gevuld, het wordt weinig gebruikt etc. etc.

Voordat je begint te flamen, het ontbreekt je aan basis kennis, als je bekent zou zijn hoe databases werken had je deze opmerking niet gemaakt.

Overigens kan je zelf kiezen of sqlserver case sensitive is of juist niet.

Syntax Wat is er primitief dan?

Datum formatering is prima, via convert kan je naar alle soorten datum types en opmaken converteren.

[Togt]

Raptorix, heb je ooit met Oracle gewerkt?
Ik heb er twee jaar als programeur (#DB'er), amateuristisch misschien, maar ik vind Oracle toch heel wat toegankelijker, er zijn veel meer tools voor verkrijgbaar.

Goed om te weten dat SQL server niet case sensitive hoeft te zijn!

[raptorix]

Op donderdag 07 maart 2002 12:07 schreef Togt het volgende:
Raptorix, heb je ooit met Oracle gewerkt?
Ik heb er twee jaar als programeur (#DB'er), amateuristisch misschien, maar ik vind Oracle toch heel wat toegankelijker, er zijn veel meer tools voor verkrijgbaar.

Goed om te weten dat SQL server niet case sensitive hoeft te zijn!

Ik werk op dit moment zijdelings met oracle omdat het aangekochte CMS hier mee werkt, als tool gebruik ik toad, op zich aardig maar gebruik het eigenlijk alleen voor simpele zaken zoals queries.

De tools die bij sqlserver zitten zijn wel degelijk zeer goed, met name de profiler ben ik zeer tevreden over.

Eigenlijk is de query analyzer die standaard installt is dus ongeveer het zelfde als toad.

De reden waarom een record dus maximaal 8000 bytes mag zijn is omdat dit de grote is van een page in sqlserver.

Overigens geld deze grote dus niet voor binary data, deze worden in aparte pages opgeslagen.

Misschien is het interessant als je even het stukje in de online books naleest, over physical database architecture in sqlserver. Het is op zich vrij droog maar ook wel weer erg interessant.

[baskabas]

Op donderdag 07 maart 2002 11:43 schreef justmental het volgende:
Gegoogled:
http://www.swynk.com/friends/Vartanyan/Access_vs_SQLServer.asp
8000 bytes per rij.
1000 kolommen max in een tabel.

[mierenneukmodus]

Een page is 8192 bytes (een rij kan niet op meerdere pages staan, dus...)
Er kunnen 1024 kollomen in een tabel

[/mierenneukmodus]

Sorry, vorige week weer een examen gehad... passed!

[Togt]

Hartelijk dank voor alle info. Ik zit hier gedetacheerd, de database is niet onder ons beheer, en elke structurele aanpassing eraan kost 2 dagen.

Het gaat ongelooflijk moeizaam wat dat betreft . . Excuus van de kritiek op SQL server. Het is niet mijn eerste keus.

[Crazy D]

offtopic:
[quote]
Op donderdag 07 maart 2002 11:54 schreef daxx909 het volgende:
[RANT]
Heb je Exact Synergy es aan de gang gezien? 100% SQL server optimized; probeer daar es aan te tippen! (Wanneer je 't in handen krijgt)
[/over RANT]
[/quote]


Ik denk dat je helemaal niet _wilt_ weten hoe Exact en E-Synergy met MSSQL omgaan (uhh dat zeg ik dus uit ervaring). Als iemand een SQL cursus nodig heeft, zijn het de ontwerpers van die en die van Globe2000) database.

[Verwijderd]

Op donderdag 07 maart 2002 11:53 schreef Togt het volgende:
Hartelijk dank voor het snelle antwoord.
[RANT]
Ongelooflijk dat een product als SQL server het op de zakelijke markt redt!

If you can't handle it, don't use it

- Case Sensitive

Dit kun je bij installatie opgeven. Default is case INsensitive

- Syntax die op zijn minst gezegd primitief is.

T-SQL is state of the art. Wat wil je nog meer? Je stored procs schrijven in Java ?

- Datum formatering is idioot!!!!

Welke datum formattering? Datums worden opgeslagen als native datetime values. Die kun je met date* functies zo formatteren als je zelf wilt. Maar dit is zelden nodig in queries op de database, want formattering van datums is iets voor gui-representation layers.

Ik weet dat de 100 fields veel zijn, maar dit is een pure temp-tabel: Veel velden worden niet gevuld, het wordt weinig gebruikt etc. etc.

je maakt veel velden aan, maar die worden zelden gebruikt. Beetje rare zaak, niet? en dan maar zeuren op het product dat je gebruikt. Wellicht eerst eens wat kennis van zaken opdoen?

[Verwijderd]

Op donderdag 07 maart 2002 12:52 schreef Togt het volgende:
Hartelijk dank voor alle info. Ik zit hier gedetacheerd, de database is niet onder ons beheer, en elke structurele aanpassing eraan kost 2 dagen.

Dat ligt niet aan SQLserver

Het gaat ongelooflijk moeizaam wat dat betreft . . Excuus van de kritiek op SQL server. Het is niet mijn eerste keus.

Ook dat ligt niet aan SQL server maar aan jouw bekrompen wereldbeeld. Oracle en SQLserver hebben op het gebied van clustering een verschil in featureset. Voor de rest is het wel zo'n beetje gelijk. SQLserver loopt wat voor op OLAP gebied. En snelheid natuurlijk.

Voor SQLserver zijn erg veel tools beschikbaar en als je niet vindt wat je zoekt dan open je VB en binnen een paar minuten heb je je eigen tool mbv de SQL-DMO components in elkaar gezet. Het is niet zo moeilijk allemaal hoor.

[Verwijderd]

Ik denk dat je helemaal niet _wilt_ weten hoe Exact en E-Synergy met MSSQL omgaan (uhh dat zeg ik dus uit ervaring).

Ik weet dat iedere update een *****-werk is, omdat er veel dingen vaak niet kloppen, of er bugjes ergens zitten. Heel irritant allemaal, maar SNEL is 't wel! (Als 't werkt |:(; heb de source gezien, wat een tricksters!)

[Verwijderd]

Op donderdag 07 maart 2002 11:27 schreef Togt het volgende:
Ik hoorde van de DB'er hier dat de tabel die we nodig hebben in onze applicatie niet past binnen SQL server. Mijn vraag aan jullie:

Ik heb een tabel waar ruw geschat een 1000 records per maand bijkomen. Ik heb 1 key, en wel ongeveer een 100 kolommen.

100 velden die een 1:1 relatie hebben met elkaar lijkt me UITGESLOTEN.

De DB'er vertelde me dat de maximale record lengte voor SQL server maximaal ong. 1900 tekens aan kan.

Nee, dit is 8 KB. Als je grote varcharvelden opneemt, kun je die beter opslaan als testfields, die worden dan buiten je record in aparte mempages opgeslagen. Zo bespaar je veel ruimte

Hoe kan een professioneel DB nou zo'n restrictie hebben?

Hoe kan een door een professional ontworpen datamodel nu 100 fields in 1 table hebben?

We hebben nu 5 verschillende tabellen met de velden opgesplitst gemaakt. Is dit dan de oplossing?
Is er een programma zoals TOAD voor Oracle maar dan voor SQL server?

Query Analyzer + SQLServer enterprise manager. Is dat dan nog niet genoeg, bak in 2 minuten je tool mbv SQL-DMO en VB. (of vbscript)

[Crazy D]

Op donderdag 07 maart 2002 13:52 schreef daxx909 het volgende:
Ik weet dat iedere update een *****-werk is, omdat er veel dingen vaak niet kloppen, of er bugjes ergens zitten. Heel irritant allemaal, maar SNEL is 't wel! (Als 't werkt |:(; heb de source gezien, wat een tricksters!)

Woei gaat wel offtopic, maar uhmm updaten vind ik nog het minst erge. Waar ik me meer zorgen om maak is de performance bij een gevulde db (synergy db bij Exact zelf schijnt rond de 130Gb te liggen) en wat voor een backbeest je nodig hebt. We hebben hier voor 15 users, en een niet eens zo heel volle db (ong. 400mb) een machine die niks anders staat te doen dan synergy hosten en die sql server draaien. 1Gb aan werkgeheugen, en tis nog maar net genoeg. En dan is onze db niet eens zo heftig gevuld.
En 't is IE only
Maar ja het is nog druk in ontwikkeling, dus hopelijk verbeterd de boel nogal (hoewel ik weinig hoop heb als je weet dat de dllhost bij ons geregeld in de 200mb ram zit, bergen activex objecten in sessie variabelen gepropt

Ok genoeg afgezeken
Otis is al genoeg ontopic bezig geweest dat ik weer onder m'n steen kruip om mee te lezen/leren

[Verwijderd]

Op donderdag 07 maart 2002 12:38 schreef TeknoGecko het volgende:

[mierenneukmodus]

Een page is 8192 bytes (een rij kan niet op meerdere pages staan, dus...)
Er kunnen 1024 kollomen in een tabel

[/mierenneukmodus]

[supermierenneukmodus]

Door de overhead die SQL Server zelf nodig heeft om de records te kunnen managen houd je 8060 bytes over per page.

Sorry, ik heb de cursus gegeven...

[/supermierenneukmodus]

[baskabas]

Op donderdag 07 maart 2002 14:51 schreef KingGeorge het volgende:

[..]

[supermierenneukmodus]

Door de overhead die SQL Server zelf nodig heeft om de records te kunnen managen houd je 8060 bytes over per page.

Sorry, ik heb de cursus gegeven...

[/supermierenneukmodus]

Daar heb je gelijk in ... was ik ff vergeten... ik zat met 8K in mijn hoofd (1024 * 8 = 8192) ... terecht gecorrigeerd!