[SQL2005] Constraint zonder Index

[gCassy]

Eenvoudige tabel:

ID	uniqueidentifier
Application	nvarchar(256)
Object	nvarchar(256)
Service	nvarchar(256)
Device	nvarchar(256)
Expires	datetime

Ik wil een contraint plaatsen op de 4 nvarchar(256) velden, zonder een extra index te creëren, maar in MS SQL Server 2005 is dit na lang googlen en hier te zoeken blijkbaar moeilijk haalbaar.
Via een insert-stored procedure wil ik het falen van de constraint opvangen en desgevallend een update doen van het "Expires" veld.

Extra Info (Situatie):
* Er kunnen gigantisch veel inserts (+threading) gebeuren op korte tijd, dus eerst count uitvoeren en afhankelijk van die count insert/update uitvoeren is geen optie.
* Volledige table lock plaatsen is misschien niet goed voor performantie redenen, maar misschien de enige optie.
* Indexen plaatsen op de combinatie van de 4 velden lukt niet, aangezien ik de grootte van 900 bytes voor een index overschrijdt door de nvarchar(256) types, die wel nodig zijn

Wat lijkt jullie het beste, verder de optie van constraints te gaan onderzoeken (indien het mogelijk is zonder indexatie), of toch naar table - lock mechanismen zoeken? Alvast bedankt.

[whoami]

Waarom wil je er geen index op hebben ?
Je kan een unique constraint of een unique index maken; echter, die unique constraint gaat achter de schermen ook een index gaan leggen.
Je kan de index wel creeëren, echter, je zal een run-time error krijgen als je index size de 900 bytes overschrijdt.

Is er geen mogelijkheid om die gegevens te normaliseren ? Application, Object, Device & Service in een aparte tabel, en dan gebruik maken van hun id's om de betreffende combinatie te maken ? Dan kan je op die id's een index leggen.

[RobIII]

En is die 256 écht nodig? Klinkt mij als een "mooie veldgrootte" en minder als een daadwerkelijk gebruikt iets. Laat eens een select max(len(Application)) op de tabel los (en idem voor de andere velden) en kijk eens of er uberhaupt ooit over de 100 tekens wordt gegaan.
Die velden lijken mij een (unieke) identificatie van <insert veldnamen hier> maar om daar 1Kb aan te spenderen is wellicht wat veel; Met 4x25 tekens (immers; nvarchar dus a-zA-Z0-9 en nog vele andere (mogelijke) leestekens)) kom je al heel gauw op voldoende combinaties voor unieke identificaties.

[ Voor 7% gewijzigd door RobIII op 20-06-2007 11:40 ]

[gCassy]

Over die runtime error maak ik me dus inderdaad zorgen, die krijg ik dus liever niet

Het gaat om het ontwikkelen van een extra laagje in een web-service framework dat moet dienen voor andere applicaties. Deze zullen door "derde" partijen worden gemaakt. Unicode varchars kan ik dus moeilijk uitschakelen en de gegevens kan ik jammer genoeg ook niet apart in tabellen gaan stockeren. Ik heb momenteel nog geen data ter beschikking, gaat om een nieuw framework.

In detail gaat het om client-applicaties die zich "subscriben" via mijn web-service op andere achterliggende server-applicaties. (ook bereikbaar via web-services). Ik hou die subscriptions bij en zorg ervoor dat de server-applicaties niet direct constant worden ge-polled.

Zal alvast even discussiëren met mijn opdrachtgever over de grootte van de velden. Echter wou ik het zo flexibel mogelijk houden.

Is manuele locking mogelijk in T-SQL? Of ben ik verplicht via transactions te werken die zelf het locking mechanisme wil bepalen?

[ Voor 21% gewijzigd door gCassy op 20-06-2007 11:54 ]

[MTWZZ]

Kun je misschien inhoudelijk wat info geven over wat je wil bereiken?

[gCassy]

MTWZZ schreef op woensdag 20 juni 2007 @ 11:46:
Kun je misschien inhoudelijk wat info geven over wat je wil bereiken?

Zie hierboven

Intussen hebben "mijn opdrachtgevers" maar beslist dat ik eerst een "count" moet doen en hierop beslissen om te inserten/updaten. Blijkbaar deed ik m'n job iets te goed en wou ik uitsluiten dat tussen de count en de effectieve insert/update er een bepaalde operatie op de tabel gebeurde... Ze willen dit eerst eens daadwerkelijk zien of het een probleem vormt ...

Is er eventueel een mogelijkheid om te zorgen dat een stored procedure als 1 transactie wordt beschouwd en niet tegelijk op de database kan worden uitgevoerd? In mijn huidige SP zitten namelijk alle mogelijke vormen van updates op de tabel ...

[RobIII]

SQL:

Begin Transaction
...
Doe je ding
...
Commit Transaction

...danwel...

Rollback Transaction

[ Voor 30% gewijzigd door RobIII op 20-06-2007 15:57 ]

[newpegasus]

Als aanvulling daarop: check na iedere mutatie op @@error, hierin staat het aantal errors dat het laatste statement heeft opgeleverd. Als dat > 1, dan moet je een rollback van de hele transactie doen.

Je kunt de mate van locking ook nog beinvloeden door het isolation level aan te passen. Hoe strenger (bv. Serializable), hoe 'beter' je records gelockt worden, maar hoe langer andere processen moeten wachten.

[ Voor 6% gewijzigd door newpegasus op 20-06-2007 16:02 ]

[Hydra]

Sowieso lijkt me een index op de 4 velden afzonderlijk nuttig, omdat je als je anders een count gaat doen een full table scan moet doen om na te kunnen gaan hoevaak waarden voorkomen.

[P_de_B]

Hydra schreef op woensdag 20 juni 2007 @ 16:19:
Sowieso lijkt me een index op de 4 velden afzonderlijk nuttig, omdat je als je anders een count gaat doen een full table scan moet doen om na te kunnen gaan hoevaak waarden voorkomen.

Als je gewoon count(*) doet, en er zijn andere indexen zal de meeste toepasselijke index voor de count() operatie wel gekozen worden. Daarvoor hoeft niet expliciet een index op de kolommen liggen.