[SQL] Hoe standaard is SQL?

[Mac_Cain13]

Ik heb voor mijn projectje een module systeem gebouwd. Dit werkt allemaal heel lekker en nu wil ik verschillende databases gaan ondersteunen. Standaard gebruik ik meestal MySQL, maar ik wil dus dat door het laden van een andere module je ook je een andere dbase kunt gebruiken. Zoals PostgreSQL, SQLite of mss zelfs Oracle.

Het schrijven van de modules is niet zo'n probleem en dat moet me allemaal wel lukken, maar mijn vraag is hoe standaard is een SQL query nou? Is het mogelijk om bij iedere dbase dezelfde SQL te gebruiken als ik hier en daar even oplet. (De SQL zal dan niet de meest efficiënte worden, maar dat moet te overleven zijn denk ik.)
Of moet ik dan wel hele rare SQL constructies gaan bouwen en kan ik beter zorgen dat iedere dbase soort zijn eigen lijstje met SQL queries krijgt? Dat is dan wel meer werk, maar wel efficiënter.

Ik zag bijvoorbeeld dat RwD in dit topic ineens een heel aparte query ging bouwen, omdat het om een Oracle dbase ging. Terwijl de oplossing die Shadowman daar geeft mij veel meer standaard lijkt.
Als ik dat zo bekijkt lijkt het erop dat mijn SQL hergebruiken vrij moeilijk word. Terwijl ik dacht dat SQL een standaard was? Of word er zoveel aan gesleuteld dat de standaard min of meer verloren is gegaan?

Mss dat er hier mensen ideeën hebben over hoe ik dit het beste zou kunnen oplossen. Voor iedere dbase aparte SQL schrijven of de SQL hergebruiken of mss heeft er iemand nog wel een geniale oplossing die ik over het hoofd zie!

[curry684]

Als je SQL-92 gebruikt slikt iedere DB het gewoon. Probleem is dat je dan geen 'geweldige stunts' uit kunt halen, de grootste verschillen tussen DB's zitten 'm in string-concats, limiting clauses (TOP tegen LIMIT) en table escaping ([user] tegen idiote backticks).

[whoami]

Als je een beetje kracht uit je DB wilt halen, dan kom je niet ver met standard SQL, en moet je wel de DB specifieke functies, keywords, etc... gaan gebruiken.

Als je een applicatie hebt, en je wilt dat die applicatie meerdere DBMS'en ondersteunt, dan kan je IMO best eens kijken naar het bridge design pattern (met dien verstande dat de taal die je gebruikt om die applicatie te bouwen OO ondersteunt).
Met het bridge design pattern kan je een implementatie van een abstractie scheiden; dat wil dus zeggen dat je bv. een class Persoon hebt, en dat die class Persoon een method 'Save' heeft. Als je de Save method van die persoon aanroept, dan zal die Save method de juiste implementatie-specifieke method voor de huidige/te gebruiken DBMS gaan gebruiken.

Hier heb ik bv een bridge gebruikt om 2 verschillende DB's te ondersteunen
[rml][ Alg/.NET] Architectuur smart client - Part II concrete case[/rml]

[ Voor 10% gewijzigd door whoami op 05-08-2004 13:56 ]

[Soultaker]

Is er trouwens een handige handleiding/referentie van SQL-92 (of een andere gangbare standaard)? Ik pak elke keer de handleiding van het DMBS waar ik toevallig mee werk, maar dan krijg je uiteraard steeds de systeemspecifieke dingen mee en moet je zelf maar zien welke overeenkomsten er bestaan tussen databasesystemen.

[drm]

curry684:
en table escaping ([user] tegen idiote backticks).

Of zelfs dubbele quotes in PostGres, waarvan ik dacht dat de laatste het bij het rechte eind had?

[Mac_Cain13]

Ok, bedankt voor de snelle reacties tot nu toe.

Zolang ik me dus aan de echte SQL-92 standaard houd is het geen probleem. Het zou idd handig zijn om eens een overzicht te hebben van wat ik daarmee kan. Als SQL-92 aan mijn eisen voldoet kan ik me daar gewoon aan houden. Weet iemand ergens zo'n handleiding. Een snelle blik op Google leverde niets op. (Zal zelf ook nog even verder zoeken)

Wat whoami noemt lijkt ook interessant. De taal die ik gebruik heeft enigsinds gebrekkige OO ondersteuning. (PHP5) Maar als SQL-92 niet voldoet. Of het er op lijkt dat het in de toekomst niet gaat voldoen, want uitbreidden word dan natuurlijk lastig is zo'n "bridge design pattern" wel interessant. Ik ga eens opzoek naar wat voorbeeldjes van dat bridge design systeem.

Verdere ideeën zijn natuurlijk altijd welkom

edit:
Ah tnx whoami voor de link naar je topic! Erg interessant ben aant lezen

[ Voor 12% gewijzigd door Mac_Cain13 op 05-08-2004 14:24 ]

[RwD]

Ik gokte maar wat op basis van die string concatenatiesuggestie en omdat de TS familie is

Maar die inner join zal volgens mij niet werken op Oracle SQL omdat mijn boekje over Oracle 8 het commando inner join niet kent. Ik kon dat niet testen omdat ik alleen de beschikking heb over TransactSQL en MySQL. OracleSQL heb ik ooit eens gebruikt...

Maar er is dus een basis voor de queries? maar ja, als je er niet veel mee kunt, kun je beter je query strings ook apart bewaren per db lijkt me

[drm]

RwD:
Maar die inner join zal volgens mij niet werken op Oracle SQL omdat mijn boekje over Oracle 8 het commando inner join niet kent.

Dat lijkt me stug, maar als dat inderdaad zo is, kun je altijd nog een equi join gebruiken.

[Mac_Cain13]

Na nog eens wat rond gekeken te hebben ben ik bang dat als ik me binnen SQL-92 moet houden ik iig verder op in mijn project in de knoei ga komen en dan alles om moet gaan bouwen. Meerdere databases ondersteunen dmv een systeem wat whoami aangaf ziet er erg goed uit en op deze manier kan ik ook nog eens alles uit een database halen wat erin zit. Ik ga maar eens in die richting denken en kijken hoe ik dit het beste toe kan gaan passen in mijn project.

Ik wil dus iig over op aparte queries per dbase, zijn er nog andere manieren dan dat whoami aangaf? Of heeft iemand nog tips over hoe ik dit het beste aan kan gaan pakken? Ik hoor het graag!

@RwD: Maakt niet uit dat je gokte, het ging erom dat je query er heel anders uit zag dan die daarboven. Je was iig makkelijk even als voorbeeldje te misbruiken

[hobbit_be]

abstract je queries gewoon als dat kan... een OO wrapper (zoals JDBC dat doet eg, en waarschijnlijk ook ODBC (no experience)). Snel Voor typen: nee, maar net zoals meeste higher level languages betere cost/performance ratio.

[Grijze Vos]

Aangezien de verschillen minimaal zijn is het misschien het handigste om gewoon 1 dbms te kiezen als 'base'. Jouw MySQL bijvoorbeeld, en dan in de andere classes voor andere dbms'en een query-translatie functie in te bouwen.

Bij lange na niet zo'n mooie oplossing als het bridge design pattern waar Whoami het over heeft, maar een stuk eenvoudiger. Kost je natuurlijk wel een beetje performance.

[BestTested!]

Ik ben laatst ook een dergelijk probleem tegengekomen en heb dat toen als volgt opgelost. Ik heb toen een module gemaakt met ongeveer een dergelijke inhoud. (in VB dus ook niet echt makkelijk voor OO)

Pseudo code:

code:

 @Param
  //queryname = name of the query
  //dbase = name of the DBMS
 @Return
  // The wanted SQL query 

Function giveMeQuery(String queryName, String dbase)
   
   if query = "UpdateBlaat"
         if dbase = "MSSQL"
           return "DezeQuery
         elseif dbase = "MYSQL"  
           return "AndereQuery"
   
   elseif query = "DeleteQuery"
          if dbase = "MSSQL"
           return "WeerAndereQuery
         elseif dbase = "MYSQL"  
           return "NogmaalAndereQuery"        
    
   elseif ...
       ...........
       ...........//Je begrijpt de bedoeling wel

Op deze manier had ik alle queries bij elkaar staan en kan ik later er ook nog makkelijk support voor een andere DBMS bij zetten.

[MSalters]

Herb Sutter was convenor van de ISO standaard commissie voor SQL, en hij haalt SQL aan als het klassieke voorbeeld van een non-standaard: Er zijn zoveel opties en varianten toegestaan, dat het aantal verschillende SQL-standaarden groter is dan het aantal implementaties.

[creative8500]

De oplossing is niet SQL92, maar een QueryFactory.

[gorgi_19]

Ik ben laatst ook een dergelijk probleem tegengekomen en heb dat toen als volgt opgelost. Ik heb toen een module gemaakt met ongeveer een dergelijke inhoud. (in VB dus ook niet echt makkelijk voor OO)

offtopic:
Geen idee in hoeverre VB al OO-elementen ondersteund, maar ik heb het idee dat dit vrij snel een niet onderhoudbaar iets kan gaan worden. Ik denk dat een abstract factory voor een DAL een iets nettere en flexibelere oplossing is.

[whoami]

Ik denk ook dat het systeem van BestTested! in ietwat grotere systemen niet echt onderhoudbaar wordt.
Wat gorgi_19 echter voorstelt is imo niet te realiseren in VB aangezien VB geen inheritance/polymorphisme kent.

[Mac_Cain13]

Bij veel dbases en/of veel queries lijkt mij het systeem van BestTested! wat onoverzichterlijk worden, omdat je if-statement dan wel heel erg lang word. Toch vind ik het idee, met een wat andere uitwerking, niet slecht.

Als je nou een giveMeQuery achtige method/functie maakt die aan de hand van de database die je gebruikt de juiste file met queries laad en vervolgens de juiste query terug geeft. Dan zit je niet met zo'n geweldig groot if-statement. De verschillende queriesstaan netjes apart per dbase in een file zodat je vrij snel de juiste query kunt vinden en aanpassen.
Daarbij is het ook simpel om iemand anders zo'n filetje te laten schrijven. (Dan hoef ik zelf niet al die queries te bouwen ) En ik kan speciale functies van iedere dbase gebruiken zodat ik me niet alleen binnen SQL-92 hoef te houden. De enige voorwaarde is dat de queries voor de verschillende dbases wel het zelfde resultaat moeten opleveren, maar dat lijkt me zo en zo een voorwaarde.

Zou zo'n soort systeem (wat volgens mij goed aansluit bij de grote van mijn projectje) goed kunnen functioneren? Of zie ik nu iets gigantisch over het hoofd en ga ik zometeen helemaal de boot in? Of vinden jullie dit zo en zo een brak systeem wat je nooit in een project zou mogen stoppen hoe klein ook. Kortom ik ben eigenlijk wel benieuwd naar wat meningen.

[whoami]

Het is een optie, maar het is dan wel mogelijk om makkelijk al je queries /tabelnamen/... te gaan bekijken en veranderen.
Hou er ook rekening mee dat je dan bij iedere query die je uitvoert, in die file moet gaan lezen (tenzij je de inhoud van die file dan gaat cachen).

[Mac_Cain13]

whoami schreef op 06 augustus 2004 @ 15:36:
Het is een optie, maar het is dan wel mogelijk om makkelijk al je queries /tabelnamen/... te gaan bekijken en veranderen.
Hou er ook rekening mee dat je dan bij iedere query die je uitvoert, in die file moet gaan lezen (tenzij je de inhoud van die file dan gaat cachen).

Ik wilde de inhoud van de file idd gaan cachen.
Het aanpassen van een query/tabelnaam is idd niet zo heel erg flexibel. Dat is wel een punt. Als blijkt dat een query een bug bevat of gewoon aangepast moet worden zal ik idd alle files door moeten om voor iedere dbase de query aan te passen, maar het lijkt me dat ik toch ergens een lijst met queries moet hebben.