Oracle auto number

[smeerbartje]

Ik heb een redelijk simpele vraag volgens, maar door een ongelukkige benaming vind ik steeds de verkeerde resultaten in Google. Ik wil namelijk een simpel auto-nummertje hebben in een query.

Bijvoorbeeld:

code:

select auto_id, naam, achternaam
  from test_table;

Output:

code:

---------------------
|0|naam0|achternaam0|
|1|naam1|achternaam1|
|2|naam2|achternaam2|
|3|naam3|achternaam3|
---------------------

Nu bestaat 'auto_id' niet als kolom, deze moet automatisch gegenereerd worden door SQL. Hoe doe ik dit?

[michelzwarts]

auto_id veld toevoegen in de database met autoincrement property

[smeerbartje]

michelzwarts schreef op dinsdag 26 januari 2010 @ 14:19:
auto_id veld toevoegen in de database met autoincrement property

Sorry, had ik moeten vermelden, ik kan de opbouw van de tabellen niet wijzigen.

[michelzwarts]

SELECT @rownum:=@rownum+1 rownum, t.*
FROM (SELECT @rownum:=0) r, mytable t;

[Verwijderd]

Ik heb hier geen oracle, maar als het goed is heeft oracle ook de row_number functie.
De query zou dan zoiets worden:
select
row_number() over (order by naam), naam, achternaam
from
test_table

edit: meer informatie is hier te vinden http://www.adp-gmbh.ch/ora/sql/analytical/row_number.html

[ Voor 19% gewijzigd door Verwijderd op 26-01-2010 14:22 ]

[smeerbartje]

Top, thanks! Hoe simpel, "select rownum from dual" is al genoeg . Mag dicht voor toekomstig gebruik.

[Janoz]

In oracle is het gebruikelijker om een sequence te gebruiken.

[ZaZ]

Ja gewoon een sequence met een trigger is de manier om het te doen

[SPee]

Maar wordt die trigger niet ná de insert uitgevoerd

Ik heb in queries regelmatig gezien:

code:

 insert into mytable values ( select myseq.nextval, 'data');

Of ligt dat aan de specifieke Oracle versie

[mkleinman]

Met SPee. Ligt niet aan een specifieke versie van Oracle. mysq.nextval is simpelweg een sequence die je gebruikt. Werkt zowiezo vanaf Oracle 7 t/m 11g.

[ZaZ]

SQL:

CREATE SEQUENCE s_jouwtable
  START WITH 1
  MAXVALUE 999999999999999999999999999
  MINVALUE 1
  NOCYCLE
  CACHE 20
  NOORDER;

CREATE OR REPLACE TRIGGER tr_jouwtable
  BEFORE INSERT OR UPDATE ON jouwtable
  FOR EACH ROW
BEGIN
  IF inserting THEN
    SELECT s_jouwtable.nextval
    INTO   :NEW.ID
    FROM   dual;
  END IF;
END;

/

In dit voorbeeld heb je het gedrag van een autonumber veld op de ID column

[cariolive23]

Janoz schreef op dinsdag 26 januari 2010 @ 14:40:
In oracle is het gebruikelijker om een sequence te gebruiken.

Ook voor een nummertje in het resultaat van een SELECT? Dat zou betekenen dat er maar 1x nummer 1 kan worden uitgegeven, de sequence telt namelijk gewoon door. De volgende keer dat je de SELECT uitvoert, krijg je dus hogere nummers dan de vorige keer.

Voor het aanmaken van unieke nummers/id's is een sequence natuurlijk ideaal, maar niet voor het genereren van regelnummers.

In PostgreSQL zou je met generate_series() of ROW_NUMBER aan de slag gaan en zeker geen sequence gebruiken. Al is een TEMP SEQUENCE natuurlijk wel mogelijk.

[Glimi]

Je kunt de ROWNUM pseudo kolom gebruiken of row_number over(), als je het nummer in de query wilt generen.

Ik snap de reden voor een sequence (en dus het storen van het het oplopende nummer) hier niet, aangezien met de eerste sortering die de deur uit is.

edit:
anders lees je de thread half en zeg je wat iedereen ook al gezegd heeft.

[ Voor 30% gewijzigd door Glimi op 26-01-2010 20:12 ]

[Verwijderd]

Wij gebruiken GUID's als primary key, misschien is dat wat voor je. Tevens gebruiken we nooit meervoudige sleutels (dus ook niet in een n-m koppeltabel).

[ Voor 44% gewijzigd door Verwijderd op 27-01-2010 09:39 ]

[Motrax]

Nee, dat is niet wat...

Wikipedia: Globally Unique Identifier

GUID is groot in opslag, geeft problemen met geclusterde indexen en is niet eens random. Bij kleine databases geen probleem, maar met grotere...

Hou het bij een sequence, dat is wat je zoekt en nodig hebt.

[Verwijderd]

Motrax schreef op woensdag 27 januari 2010 @ 09:43:
Nee, dat is niet wat...

Wikipedia: Globally Unique Identifier

GUID is groot in opslag, geeft problemen met geclusterde indexen en is niet eens random. Bij kleine databases geen probleem, maar met grotere...

Hou het bij een sequence, dat is wat je zoekt en nodig hebt.

Het geeft geen enkel probleem met geclusterde indexen (als je je hoofd gebruikt) in Oracle en ik durf met enige zekerheid te stellen dat in beide applicaties de hoeveelheid data/records niet gering is (aangezien ze bij een aantal grote Zwitsere banken draaien). De geclusterde indexen werken primagoed. Erg fijn en meer performant dan een index op een id alleen. De 16 byte opslag is natuurlijk een non-argument.
Makkelijker mergen, overal uniek, geen roundtrip voor het genereren van nieuwe ID's,

[ Voor 12% gewijzigd door Verwijderd op 27-01-2010 10:33 ]

[JaQ]

Verwijderd schreef op woensdag 27 januari 2010 @ 10:19:
Het geeft geen enkel probleem met geclusterde indexen (als je je hoofd gebruikt) in Oracle en ik durf met enige zekerheid te stellen dat in beide applicaties de hoeveelheid data/records niet gering is (aangezien ze bij een aantal grote Zwitsere banken draaien).

FUD? (in ieder geval onaardig)

Verwijderd schreef op woensdag 27 januari 2010 @ 10:19:
De geclusterde indexen werken primagoed. Erg fijn en meer performant dan een index op een id alleen.

Sinds wanneer haal jij enkel de waarde van de primary key uit de database? Als je een flinke primary key hebt (en dat is een GUID) en dan ook nog eens de waarde van de PK (niet enkel de reference) gaat opslaan, dan kan je relatief weinig waarden in 1 blok kwijt. Gevolg is dat je dus lekker extra veel I/O's maakt. One size fits all bestaat niet binnen databases, net zoals de go_fast parameter of andere marketing bla bla die de gemiddelde sales rep van Oracle je aansmeert.

Verwijderd schreef op woensdag 27 januari 2010 @ 10:19:
De 16 byte opslag is natuurlijk een non-argument.

size matters (aantal rijen in een blok, rowchaining, etc etc.... )

Verwijderd schreef op woensdag 27 januari 2010 @ 10:19:
Geen roundtrip voor het genereren van nieuwe ID's,

Niet meer nodig vanaf 11.1

[Verwijderd]

JaQ schreef op woensdag 27 januari 2010 @ 16:11:
[...]

FUD? (in ieder geval onaardig)

Niet meer nodig vanaf 11.1

FUD? Ik bedoel in ieder geval niets onaardig. Daarnaast was ik niet degene die de suggestie met af deed.

Sinds wanneer haal jij enkel de waarde van de primary key uit de database?

Brainfart idd.

Desalnietteplus ben ik naar aanleiding van deze topic (en dan voornamelijk de replies op mijn reply, zoals en jouw baan) eens verder op onderzoek gegaan naar de PRO's en CON's van GUID/int. Uiteraard heb ik dit model niet zelf ontwikkeld en beide applicaties zijn enigszins legacy (VB6.0). Zomaar even switchen naar een andere structuur zal domweg niet gaan, maar het is het waard om te onderzoeken (zeker aangezien ik op professioneel vlak weinig met databases/Oracle in aanraking kom, wat op het punt staat drastisch te veranderen). Het is misschien ook handig om te vermelden dat beide applicaties door meer dan 1000 mensen tegelijk worden gebruikt, waarvan enkele 100en zich continu bezighouden met de pakketten. Financiele dingen.

Nogmaals, ik bedoel absoluut niets als betweterij of boe-geroep, ik ben zelf een groentje (en al helemaal op DB gebied) en daar ben ik me terdege van bewust, maar ot nu toe lijkt het vooral, zoals zo vaak, een 'heilige oorlog', zoals die tussen een natuurlijke en surrogaatsleutel.

Na dit gelezen te hebben:
http://ingol.nl/blog/2009...or-not-to-guid-on-oracle/
http://originalwhatever.b...uids-as-primary-keys.html
http://preferisco.blogspo...i-master-replication.html
http://feuerthoughts.blog...uential-oracle-guids.html
http://www.codinghorror.com/blog/archives/000817.html
http://databases.aspfaq.c...e-for-my-primary-key.html
http://www.kindblad.com/2...ueidentifier-vs-identity/

Kom ik tot deze conclusie:
- Leesbaarheid: hoewel ik het punt op zich begrijp, vind ik het geen deal-breaker, als een integer groot wordt verdwijnd de human-readability ook.
- Opslagprijs/capaciteit vind ik op zich ook geen issue, stel voor het gemak dat er 100 miljoen records in de database zitten. 12 * 100.000.000 / 1024 /1024 = 1,1 gigabyte over de gehele database. Ik weet niet wat voor raid setup normaal is voor dit soort gevallen, maar als we even uitgaan van RAID5, met 3 schijven, dus 3,3 gigabyte opslag, kost het in verhouding nog niets.
- Performance kan een issue zijn. De meesten die gebruik maken van onze applicatie werken met een lokale dataset en dus komen er veel merges bij kijken dan is een sequence gewoon niet handig. Dat mergen lijkt me een uitstekend argument om wel voor een GUID strategie te kiezen.

Dus: beide hebben voor- en nadelen en het is maar net welke strategie het best bij jouw applicatie past.
Voor een huis-, tuin- en keukenprojectje zal het allemaal niet uitmaken.
Nogmaals, dit is getypt vanuit het oogpunt van een groentje, die een mening probeert te vormen over bepaalde ontwikkelstrategi"en. Tips van ervaren DBA's zoals jij zijn altijd welkom natuurlijk

[ Voor 89% gewijzigd door Verwijderd op 27-01-2010 18:39 ]

[JaQ]

Verwijderd schreef op woensdag 27 januari 2010 @ 17:09:
FUD? Ik bedoel in ieder geval niets onaardig. Daarnaast was ik niet degene die de suggestie met af deed.

Wellicht lag dat aan mijn interpretatie

En nu offtopic:

Verwijderd schreef op woensdag 27 januari 2010 @ 17:09:
Kom ik tot deze conclusie:
- Leesbaarheid: hoewel ik het punt op zich begrijp, vind ik het geen deal-breaker, als een integer groot wordt verdwijnd de human-readability ook.

Het argument tegen leesbaarheid is het risico dat er programmameurs de sleutels hard incoderen (want ze begrijpen de "logica" achter de sleutel ). Tevens moet je je afvragen of je eigenlijk wel wilt dat "humans" de technische sleutel "begrijpen".

Verwijderd schreef op woensdag 27 januari 2010 @ 17:09:
- Opslagprijs/capaciteit vind ik op zich ook geen issue, stel voor het gemak dat er 100 miljoen records in de database zitten. 12 * 100.000.000 / 1024 /1024 = 1,1 gigabyte over de gehele database. Ik weet niet wat voor raid setup normaal is voor dit soort gevallen, maar als we even uitgaan van RAID5, met 3 schijven, dus 3,3 gigabyte opslag, kost het in verhouding nog niets.

Oracle databases en RAID5 is een eigen heilige oorlog op zich, dat is voor een heel ander draadje. Maar de hoeveelheid opslag en performance (je volgende punt) is precies datgene wat het probleem is. Wat ik nu ga roepen is een basale uitleg (wellicht voelt een andere DBA zich geroepen om me te vertellen dat ik nuance mis ):

Alle sleutels (zowel primary, foreign als unique) worden in principe geïndexeerd. Dit betekent dat je waarde van een sleutel in ieder geval al 2 maal opslaat. Een integer pakt vergeleken met een varchar kolom minder bits (die snap je?). Als vervolgens een multi-byte characterset (bijvoorbeeld UTF-8) gebruikt wordt, zal de varchar nog meer "ruimte" gebruiken. Nu weet ik best dat een varchar2 kolom in principe enkel de ruimte gebruikt die je in gebruikt neemt, dus een varchar2(2000) waar je iets van 10 karakters in plaatst neemt in de tabel maar "de ruimte" 10 karakters. Dit geldt echter niet voor een index. Een index moet er rekening mee houden dat je die ruimte later alsnog kan gebruiken (door een update), dus in je index neemt die waarde wel de fysieke ruimte 2000 karakters in.

Nu naar performance. Performance in een database is in principe met zo min mogelijk I/O acties (lezen) het resultaat produceren. Data in een Oracle database wordt in zogenaamde "blokken" opgeslagen. De meeste hedendaagse Oracle database hebben een block-size van 8k. Dat gecombineerd met een andere setting db_file_multiblock_read_count) bepaald hoeveel data er met 1 I/O actie wordt ingelezen. Bij een goed getuned systeem wordt deze waarde gekoppeld aan de capaciteiten van een OS. Bij Linux is de optimale waarde 1MB. Dit betekent dat 1 I/O actie in ieder geval 1MB data ophaald per keer. (grofweg). Dat is dus OF 1 MB data OF 1 MB index. Nu terug naar de kolombreedte: door bredere kolommen te maken, past er minder data in een blok en worden er per I/O minder rijen opgehaald. Dit zorgt er dus voor dat logische sleutels (die bijna altijd varchar2 en "breder" zijn dan betekenisloze sleutels, dus meer opslag vereisen) slechter performen.

Uiteraard zijn er uitzonderingsssituaties te bedenken, maar deze "rule of thumb" kan je wel volgen.

Verwijderd schreef op woensdag 27 januari 2010 @ 17:09:
- Performance kan een issue zijn. De meesten die gebruik maken van onze applicatie werken met een lokale dataset en dus komen er veel merges bij kijken dan is een sequence gewoon niet handig. Dat mergen lijkt me een uitstekend argument om wel voor een GUID strategie te kiezen.

Gezien mijn eerdere betoog over blok-grootte lijkt het "mergen" geen argument. Ten tweede ontstaat het risico dat gegevens "gemerged" worden die niet gemerged zouden moeten kunnen worden.

Door het aanleggen van constraints (bijvoorbeeld sleutels) in je database voeg je kennis toe die zwaar opweegt tegen "query-gemak". De optimizer in de Oracle database (het stukje intelligentie dat het optimale query-path bepaald) maakt gebruik van deze constraints. Ergo: bij gebruik van een Oracle database ALTIJD constraints aanleggen. Query-gemak kan je overigens altijd maken door "views" aan te maken.

Verwijderd schreef op woensdag 27 januari 2010 @ 17:09:
Voor een huis-, tuin- en keukenprojectje zal het allemaal niet uitmaken.

Dit ben ik weer wel met je eens, maar daar hadden we het niet over. Je begon immers te schermen met grote bank en veel gebruikers (vandaar mijn eerdere FUD opmerking ). Het risico bestaat echter altijd dat huis-tuin-keuken projectje wel groot wordt en achteraf omsleutelen gebeurd eigenlijk nooit.

[Verwijderd]

Bedankt voor je uitleg , komende dagen zal ik kennis gaan maken met de bewuste datamodellen en zal ik meteen eens wat uitgebreider doorvragen naar de redenenen voor de GUID's.
Veranderen zal het niet, daar is het allemaal te groot voor, maar het is op z'n minst leerzaam.

[RobIII]

JaQ schreef op donderdag 28 januari 2010 @ 10:31:
Alle sleutels (zowel primary, foreign als unique) worden in principe geïndexeerd. Dit betekent dat je waarde van een sleutel in ieder geval al 2 maal opslaat. Een integer pakt vergeleken met een varchar kolom minder bits (die snap je?). Als vervolgens een multi-byte characterset (bijvoorbeeld UTF-8) gebruikt wordt, zal de varchar nog meer "ruimte" gebruiken. Nu weet ik best dat een varchar2 kolom in principe enkel de ruimte gebruikt die je in gebruikt neemt, dus een varchar2(2000) waar je iets van 10 karakters in plaatst neemt in de tabel maar "de ruimte" 10 karakters. Dit geldt echter niet voor een index. Een index moet er rekening mee houden dat je die ruimte later alsnog kan gebruiken (door een update), dus in je index neemt die waarde wel de fysieke ruimte 2000 karakters in.

Ik zie de relatie met een GUID (en indexed GUID) niet Een GUID is feitelijk niets meer dan een huge-ass (128 bit) integer. Niet meer en niet minder. (That is: tenzij Oracle een GUID als varchar opslaat Lijkt me stug, maar ik ben geen Oracle kenner).

Die paar bytes die je per page opoffert aan een GUID itt een (big)int zijn te verwaarlozen IMHO.

JaQ schreef op donderdag 28 januari 2010 @ 10:31:
Ten tweede ontstaat het risico dat gegevens "gemerged" worden die niet gemerged zouden moeten kunnen worden.

Een kans van 1 op 2^128 Dat is een as-tro-no-misch groot getal. Good luck on that one. Fat chance. (Feitelijk een piep klein beetje minder dan 2^128 omdat er (from the top of my head) een bit of 2~4 gereserveerd zijn voor bepaalde zaken).

.edit: Het schijnt dat Oracle 't zou moeten opslaan als RAW (fugly page zeg ). As said, ik ben niet bekend met Oracle maar het wordt zover ik begrijp geïnterpreteerd als byte-array. Je zult wel wat overhead hebben (al is het maar omdat CPU's niet met 128 bits values werken, althans niet zonder gekke stunts) maar lijkt me verwaarloosbaar en de voordelen van een GUID zeker niet teniet doen.

[ Voor 35% gewijzigd door RobIII op 28-01-2010 11:22 ]

[Janoz]

Een discussie over GUID is hier ook al eens geweest:

[MySQL]Auto increment recount

Ik sta iig nog steeds achter mijn standpunt dat een GUID oplossing een oplossing is die pas gekozen moet worden wanneer blijkt dat andere oplossingen niet toereikend zijn. Zolang je geen distributed systemen hebt die langere tijd los van elkaar moeten kunnen blijven opereren is er al vaak een betere oplossing mogelijk.

[JaQ]

RobIII schreef op donderdag 28 januari 2010 @ 11:10:
Ik zie de relatie met een GUID (en indexed GUID) niet Een GUID is feitelijk niets meer dan een huge-ass (128 bit) integer. Niet meer en niet minder. (That is: tenzij Oracle een GUID als varchar opslaat Lijkt me stug, maar ik ben geen Oracle kenner).

Oracle gebruikt een raw (maar dat had je al gevonden), maar dat staat los van mijn betoog omtrent een passende sleutel voor een systeem. Overigens heeft raw weer hele andere technische problemen binnen Oracle, maar dat is een andere discussie.

Echter, misschien zie jij de relatie niet maar ik heb dagelijks te maken met de gevolgen van het achteloos kiezen voor oplossingen als GUID (of andere waanzin als constraints in applicaties ipv de database) waarna vervolgens geklaagd wordt dat het systeem te traag performed.

RobIII schreef op donderdag 28 januari 2010 @ 11:10:
Een kans van 1 op 2^128 Dat is een as-tro-no-misch groot getal. Good luck on that one.

Maar what if? De kans is groter dan 0 (en laat dat nou de kans zijn die je hebt als je op de juiste manier gebruikt maakt van sequences binnen Oracle).

RobIII schreef op donderdag 28 januari 2010 @ 11:10:
As said, ik ben niet bekend met Oracle maar het wordt zover ik begrijp geïnterpreteerd als byte-array. Je zult wel wat overhead hebben (al is het maar omdat CPU's niet met 128 bits values werken, althans niet zonder gekke stunts) maar lijkt me verwaarloosbaar en de voordelen van een GUID zeker niet teniet doen.

Dat ligt er maar net aan of je die voordelen nodig hebt. Er bestaat geen go_fast button, net zoals er geen one_size_fits_all oplossing bestaat.

[RobIII]

JaQ schreef op donderdag 28 januari 2010 @ 11:47:
Oracle gebruikt een raw (maar dat had je al gevonden)

Daar ben ik dan ook gelukkig niet (verder) bekend mee, maar ik geloof je op je woord

JaQ schreef op donderdag 28 januari 2010 @ 11:47:
maar dat staat los van mijn betoog omtrent een passende sleutel voor een systeem.

Het moet, d'uh, wel "passend" zijn ja. Net als elk ander field.

JaQ schreef op donderdag 28 januari 2010 @ 11:47:
Echter, misschien zie jij de relatie niet maar ik heb dagelijks te maken met de gevolgen van het achteloos kiezen voor oplossingen als GUID (of andere waanzin als constraints in applicaties ipv de database) waarna vervolgens geklaagd wordt dat het systeem te traag performed.

Trust me, ik zie zelf genoeg Ik zeg ook niet dat je "achteloos" moet kiezen voor een GUID; die keuze moet je overwegen en toepassen wanneer van toepassing. En dat is (o.a.) wanneer te maken hebt met datasets die niet meteen in dezelfde DB opgenomen zijn maar later gemerged worden etc.

JaQ schreef op donderdag 28 januari 2010 @ 11:47:
Maar what if? De kans is groter dan 0 (en laat dat nou de kans zijn die je hebt als je op de juiste manier gebruikt maakt van sequences binnen Oracle).

Ik weet niet wat de "juiste manier van sequences binnen Oracle" is, maar wat ik vaak tegen kom zijn allerlei "homebrew" oplossingen om merge-conflicten tegen te gaan die uiteindelijk buggier zijn dan "gewoon" een GUID (of andere slimme, vaak DBMS-specifieke, DBMS-eigen oplossing).

[JaQ]

RobIII schreef op donderdag 28 januari 2010 @ 11:58:
Het moet, d'uh, wel "passend" zijn ja. Net als elk ander field.

Helaas is dat minder d'uh dan (jij en) ik zou hopen . De grootste oorzaak daarvoor is in mijn beleving het niet kennen van de consequenties.

RobIII schreef op donderdag 28 januari 2010 @ 11:58:
Ik weet niet wat de "juiste manier van sequences binnen Oracle" is, maar wat ik vaak tegen kom zijn allerlei "homebrew" oplossingen om merge-conflicten tegen te gaan die uiteindelijk buggier zijn dan "gewoon" een GUID

Tot hier ben ik het met je eens, homebrew oplossingen missen regelmatig de intelligentie die je "koopt" met een standaardoplossing.

RobIII schreef op donderdag 28 januari 2010 @ 11:58:
(of andere slimme, vaak DBMS-specifieke, DBMS-eigen oplossing).

Ik ben fel tegenstander van database-onafhankelijk ontwikkelen van software / queries, zoals dat zo mooi genoemd wordt. (en dat is niet omdat ik Oracle DBA ben) of is dat niet waar je op doelt?

RobIII schreef op donderdag 28 januari 2010 @ 11:58:
Trust me, ik zie zelf genoeg

God-damn wat een verhaal! Echt iedere fout uit het boekje....

[ Voor 11% gewijzigd door JaQ op 28-01-2010 13:35 ]

[RobIII]

JaQ schreef op donderdag 28 januari 2010 @ 13:29:
Ik ben fel tegenstander van database-onafhankelijk ontwikkelen van software / queries, zoals dat zo mooi genoemd wordt. (en dat is niet omdat ik Oracle DBA ben) of is dat niet waar je op doelt?

Voor beiden (DBMS afhankelijk/onafhankelijk) is in bepaalde situaties iets te zeggen; dat is een oorlog an sich. Ik zweef tussen beiden; maar dat is dus juist omdat ik weet dat het soms prima kan (of toegestaan is) om DBMS-specifieke zaken te gebruiken en soms doe je 't liever niet.

[cariolive23]

JaQ schreef op donderdag 28 januari 2010 @ 13:29:
Ik ben fel tegenstander van database-onafhankelijk ontwikkelen van software / queries, zoals dat zo mooi genoemd wordt. (en dat is niet omdat ik Oracle DBA ben) of is dat niet waar je op doelt?

+1

Helemaal mee eens, en dat is niet omdat ik PostgreSQL DBA ben . Geen enkele database kan fatsoenlijke performance leveren wanneer een applicatie zo is geschreven dat het op de meest debiele systemen nog moet werken en applicaties vooral geen gebruik mogen maken van de sterke punten van een database. Functioneel gaat het wel goed, een INSERT is een INSERT en een SELECT is een SELECT, maar de performance, dat is om te janken!

Vrijwel alle performance problemen die ik tegenkom, zijn terug te voeren op beroerde applicaties die de database onvoldoende aan het werk zetten en domme queries, denk aan 1000x 1 record opvragen i.p.v. 1x 1000 records opvragen.

[JaQ]

RobIII schreef op donderdag 28 januari 2010 @ 13:38:
Voor beiden (DBMS afhankelijk/onafhankelijk) is in bepaalde situaties iets te zeggen; dat is een oorlog an sich. Ik zweef tussen beiden; maar dat is dus juist omdat ik weet dat het soms prima kan (of toegestaan is) om DBMS-specifieke zaken te gebruiken en soms doe je 't liever niet.

Het "grote altijd werkende" DBA antwoord: it depends Maar je hebt gelijk, er zijn situaties te bedenken waarin je je niet wilt vastpinnen op technologie van derden.

cariolive23 schreef op donderdag 28 januari 2010 @ 13:43:
Geen enkele database kan fatsoenlijke performance leveren wanneer een applicatie zo is geschreven dat het op de meest debiele systemen nog moet werken en applicaties vooral geen gebruik mogen maken van de sterke punten van een database.

Ik doelde meer op vendor-specifieke zaken

[ Voor 26% gewijzigd door JaQ op 28-01-2010 13:48 ]