[SQL] PL/SQL VS MYSQL

[akakiwi]

edit:

TOPIC title moet eigenlijk PL/SQL VS T-SQL zijn

Hallo allemaal,

Ik werk al 4 jaar met MYSQL via SQL7 server en SQL2000 server van M$.
Sinds 6 maanden heb ik op school les in ORACLE SQL, en ik moet zeggen dat daar ontzettend vette dingen in zitten.
Wanneer je bijvoorbeeld kijkt naar het PL/SQL gedeelte, dan kunnen daar ontzettend vette dingen mee.
Een van de dingen waar ik op doel, is het verankeren van variabelen aan datatypes zoals ze in een COLUMN zijn gedefinieerd.

Stel, je hebt een TABLE.

code:

TBL_Test
-----------|-----------------------
Id         | NUMBER
Testwaarde | VARCHAR2(100)

en je hebt een SP

code:

CREATE OR REPLACE PROCEDURE SP_Test
  DECLARE TestId TBL_Test.Id%TYPE;

Dan ken je op deze manier (anchoring) het type (NUMBER) van het Id in TBL_Test toe aan de variabele TestId. Wanneer de column waar je naar refereerd van type veranderd, dan veranderd die in SP_Test automatisch mee, en hoef je je dus geen zorgen te maken of alle variabele declaraties nog kloppen in je functies en stored procedures.

Nu heb ik al een hoop overeenkomsten gevonden tussen PL/SQL en MYSQL, zoals o.a.
%notfound == @@FETCH_STATUS <> 0
%found == @@FETCH_STATUS = 0
EXCEPTION == @@ERROR
enz....enz....

Wat ik dus niet gevonden krijg is hoe ik in MYSQL variabelen veranker aan het type van columnen.

Heeft iemand enig idee of dit kan, en zo ja, hoe??

Alvast bedankt, en dikke vette

edit:

== staat voor "PL/SQL overeenkomstig met MYSQL"

[ Voor 6% gewijzigd door akakiwi op 25-02-2003 15:03 . Reden: verduidelijking ]

[ACM]

Ik snap je vraag niet zo... Mysql heeft geen PL/SQL of andere vorm van procedurele taal, wat wil je nou eigenlijk bereiken (en dus niet hoe)?
Als je van een bepaald resultset wilt weten wat iets is zou je naar de variant van deze php functie in jouw taal kunnen zoeken:
http://www.php.net/manual/en/function.mysql-field-type.php
(in C/C++ zal ie precies zo heten)

En mocht je willen weten hoe je tabel opgebouwd is, zie DESC tabelnaam.

[drm]

Wat ik dus niet gevonden krijg is hoe ik in MYSQL variabelen veranker aan het type van columnen.

Ik ben bang dat je MySQL overschat Volgens mij kan dat nl. helemaal niet

[akakiwi]

ACM
Ik weet dat MYSQL geen procedurele taal heeft, maar omdat ik al zoveel overeenkomsten gevonden had tussen het PL gedeelte van PL/SQL en MYSQL, had ik gehoopt dat MYSQL de funties van PL/SQL ook zou kunnen uitvoeren, zij het met een andere syntax.

drm
Ik hoop niet dat ik MYSQL overschat en dat het op de een of andere manier wel mogelijk is, want stoer is het zeker.

[drm]

Wat denk je er dan precies aan te hebben, want MySQL heeft geen stored procedures of iets van die strekking, en geen foreign-key ondersteuning... Waar wil je precies heen, wat wil je precies voor elkaar krijgen, want dat ontgaat me nu volledig.

[ACM]

akakiwi schreef op 25 February 2003 @ 08:18:
ACM
Ik weet dat MYSQL geen procedurele taal heeft, maar omdat ik al zoveel overeenkomsten gevonden had tussen het PL gedeelte van PL/SQL en MYSQL, had ik gehoopt dat MYSQL de funties van PL/SQL ook zou kunnen uitvoeren, zij het met een andere syntax.

De grootste kracht van PL/SQL is volgens mij juist dat je zelf complete en evt complexe logica kan toevoegen aan je database, niet dat je een paar functies kunt uitvoeren die al voorgedefinieerd zijn

En dan kan het al helemaal niet in mysql, zoals drm al zegt, ik denk ook dat mysql wat overschat
Want als het uberhaupt al kan, wat kan je er dan verder mee? In mysql, de commandline clienttool dan, kan je wel variabelen gebruiken en definieren, maar echt krachtig is dat niet en dat werkt sowieso weer niet in andere omgevingen.

[whoami]

Ik snap de topicstarter niet als hij in z'n eerste zin zegt:

Ik werk al 4 jaar met MYSQL via SQL7 server en SQL2000 server van M$.

Hoe kun je met MySQL werken via SQL Server?
Bedoel je hier niet SQL of zelfs T-SQL (de MS tegenhanger van Oracle's PL/SQL)?

[whoami]

drm schreef op 25 February 2003 @ 08:10:
[...]
Ik ben bang dat je MySQL overschat Volgens mij kan dat nl. helemaal niet

ACM schreef op 25 February 2003 @ 08:23:
[nohtml]
[/nohtml]

En dan kan het al helemaal niet in mysql, zoals drm al zegt, ik denk ook dat mysql wat overschat

Sterker zelfs..... Ik ben er zeker van dat je MySQL overschat.

Oracle is een RDBMS en MySQL is dat niet. Zoals elevator (ele) eens gezegt heeft:

MySQL is een sorry excuse voor een flat file system met indexen

Oracle met MySQL vergelijken is hetzelfde als een Rolls Royce vergelijken met een step.

Maar, om nog eens op m'n eerdere vraag terug te komen:
wat bedoel je precies met MySQL gebruiken via SQL Server? Bedoel je hier niet ipv MySQL gewoon SQL of T-SQL?

[curry684]

drm schreef op 25 februari 2003 @ 08:10:
[...]
Ik ben bang dat je MySQL overschat Volgens mij kan dat nl. helemaal niet

Wellicht voor TS interessant om eens naar PostgreSQL te kijken, de andere Open Source database. Lang niet zo snel als MySQL, maar dat komt dan ook omdat het views, foreign keys, SQL e.d. ondersteunt en daardoor veel meer in de buurt komt van commerciele oplossingen zoals SQL Server en Oracle.

[ACM]

whoami schreef op 25 februari 2003 @ 10:23:
Oracle met MySQL vergelijken is hetzelfde als een Rolls Royce vergelijken met een step.

Nah, een Bentley met een golf gti denk ik, ze kunnen beiden heel hard, maar zelfs als je er bij de golf veel moeite voor doet kan ie uiteindelijk nog niet zo hard als de Bentley. Voor kleine stukjes zul je echter vaak sneller zijn met de golf

Maar de Bentley is daar natuurlijk wel hardstikke luxe en comfortabel bij, terwijl voor de kart alle "overbodige" luxe weggegooid is. Dan wint de Bentley het dus door zijn betere "engine" en handige technieken.

curry684 schreef op 25 februari 2003 @ 10:28:
Wellicht voor TS interessant om eens naar PostgreSQL te kijken, de andere Open Source database. Lang niet zo snel als MySQL, maar dat komt dan ook omdat het views, foreign keys, SQL e.d. ondersteunt en daardoor veel meer in de buurt komt van commerciele oplossingen zoals SQL Server en Oracle.

Zie voorgaande metafoor van me
PostgresQL zou in dat verband een Mercedes Diesel zijn, redelijk luxe en op langere afstanden behoorlijk vlot.

Imho valt het "lang niet zo snel" wel mee, maar je moet bij Postgres wel meer moeite doen om te tunen (hoewel je de performance ook beter kan analyseren door betere logging en explain statements )

edit:

Golf ipv kart, met een kart mag je meestal niet de weg over enzo

[ Voor 49% gewijzigd door ACM op 25-02-2003 10:54 ]

[akakiwi]

whoami schreef op 25 February 2003 @ 09:54:
Ik snap de topicstarter niet als hij in z'n eerste zin zegt:

[...]


Hoe kun je met MySQL werken via SQL Server?
Bedoel je hier niet SQL of zelfs T-SQL (de MS tegenhanger van Oracle's PL/SQL)?

hmmm....
Dat taaltje waarin ik dan al 4 jaar werk, dat is toch gewoon MySQL??
Of vergis ik me daar dan al al die tijd in.

Maar, ik zal me vergist hebben in de aanduiding van de taal, want, wanneer je met SQL-server werkt, dan kun je keurig Stored Procedures (richting drm) aanmaken, en dan kan het heel handig zijn om in die Stored Procedure een anchor te leggen naar het type van de column waar je naar verwijst ipv dat je keihard zegt Id NUMERIC.

Mijn excuses dat ik nogal onduidelijk ben geweest.

[whoami]

[nohtml]

akakiwi schreef op 25 februari 2003 @ 14:14:
[...]


hmmm....
Dat taaltje waarin ik dan al 4 jaar werk, dat is toch gewoon MySQL??
Of vergis ik me daar dan al al die tijd in.

MySQL is een DBMS, zoals je SQL Server, PostgreSQL, Oracle hebt..... (Alhoewel je deze niet met MySQL mag vergelijken, zie hoger. )
SQL is een taal: Structured Query Language. HIermee kan je gegevens selecteren en manipuleren, en ook de structuur van je database mee maken/veranderen.

Maar, ik zal me vergist hebben in de aanduiding van de taal, want, wanneer je met SQL-server werkt, dan kun je keurig Stored Procedures (richting drm) aanmaken, en dan kan het heel handig zijn om in die Stored Procedure een anchor te leggen naar het type van de column waar je naar verwijst ipv dat je keihard zegt Id NUMERIC.

Dat dacht ik ook al.
In SQL Server gebruik je dus de taal SQL, meer specifiek zelfs T-SQL (Transact SQL). T-SQL is de tegenhanger van Oracle's PL/SQL. T-SQL kent dus ook de IF WHILE, .... statements.

[drm]

akakiwi:
hmmm....
Dat taaltje waarin ik dan al 4 jaar werk, dat is toch gewoon MySQL??
Of vergis ik me daar dan al al die tijd in.

Vandaar dus alle spraakverwarring in dit topic.

http://www.mysql.com

Maar, ik zal me vergist hebben in de aanduiding van de taal, want, wanneer je met SQL-server werkt, dan kun je keurig Stored Procedures (richting drm) aanmaken, en dan kan het heel handig zijn om in die Stored Procedure een anchor te leggen naar het type van de column waar je naar verwijst ipv dat je keihard zegt Id NUMERIC.

Dat snap ik nu, maar dat heeft dus niets met MySQL te maken

Mijn excuses dat ik nogal onduidelijk ben geweest.

np

[justmental]

Het nut van %type declaraties wordt trouwens over het algemeen gruwelijk overschat.
Gebruik van deze declaraties biedt je nog steeds niet de mogelijkheid om zonder code-aanpassing te switchen van datatypen vanwege datatype conversies.
Het enige waar ze nog wel handig zijn is in de variabele declaraties van character typen, zo kun je de lengte van het datatype vrijwel probleemloos varieren.

Je komt ze ook nog wel eens tegen in functie-aanroepen, waar ze uberhaupt weinig nut hebben omdat hier alleen het datatype relevant is, en dus niet de lengte.

[akakiwi]

hmmm.....
Het is ook niet de bedoeling om zomaar te switchen van willekeurig welk datatype, maar de lengte is wel van belang, en zeer makkelijk wanneer je deze in de database wijzigd, en dat dan de verwijzingen in de SP's en functies meteen zijn aangepast.

Justmental, je zegt dat in functies alleen het datatype, en niet de lengte relevant is, maar string waardes worden bijvoorbeeld wel afgekapt op de lengte die je hebt gedeclareerd wanneer je een functie aanroep doet waar je een string (VARCHAR) waarde aan mee geeft, dus helemaal gevoelloos zijn functies daar niet voor.

[justmental]

akakiwi schreef op 25 februari 2003 @ 15:02:
Justmental, je zegt dat in functies alleen het datatype, en niet de lengte relevant is, maar string waardes worden bijvoorbeeld wel afgekapt op de lengte die je hebt gedeclareerd wanneer je een functie aanroep doet waar je een string (VARCHAR) waarde aan mee geeft, dus helemaal gevoelloos zijn functies daar niet voor.

In de functiedeclaratie is het niet relevant. Daar staat bijvoorbeeld zoiets:

code:

function get_parameter ( p_par_name in varchar2 ) is

Geen lengte dus achter de varchar, als daar wel wat staat dan wordt het genegeerd.
Als je met een daar met een %type declareert dan wordt ook alleen het type meegenomen.