Discussion :

[SQLpro]

- curseurs trop lents et peu performants

Par rapport à quoi ??? Les voitures, c'est trop triste !!!
Par nature les curseurs sont beaucoup plus lent que les requêtes. Les curseurs rendent le code itératif. Or un SGBDR est par nature ensembliste. Utiliser des curseurs pour des traitements est donc stupide, d'autant qu'il y a aujourd'hui toutes les techniques possible pour éviter 100% des curseurs !

- pas de typage relatif (%TYPE en Oracle)

Cela n'existe pas en SQL. Ce n'est pas parce que Oracle fait n'importe quoi pour éviter SQL et qui plus est franchement pas génial (CONNECT BY, TO_NUMBER, MINUS, =!, DECODE, CREATE SYNONYM....) qu'il faut en imiter ses stupidités. Pour cela MS SQL Server est plus respectueux de la norme SQL. N'oubliez pas que SQL est un langage normatif. Au lieu d'apprendre ORACLE, vous auriez mieux fait d'apprendre le langage SQL. Mon livre, comme mon site web peut vous y aider !

- triggers limités

Là vous avez raison. Mais vous êtes pas futé, car un déclencheur ensembliste peut devenir itératif en utilisant un CURSOR, ce que font de manière interne les SGBDR qui prévoit la syntaxe FOR EACH ROW !!! et donc les mauvaises performances qui vont avec !!!

- pas de transactions autonomes

N'étant spécialiste des bases de données que depuis 20 ans, je ne connais pas les transactions autonomes... Pourriez vous m'en dire plus sur ce concept ?

- pb déclarations d'UDF

Encore une fois votre méconnaissance du langage SQL vous fait dire des bêtises. Voir la réponse que j'ai apporté ici :
http://www.developpez.net/forums/d69...t/#post4425537

Le client a choisi SQL Server par choix budgétaire. Je le respecte (le client), mais je pleure derrière.

Il est dommage d'avoir appris à conduire une twingo. Il aurait été plus intelligent d'apprendre à conduire une voiture ! C'est la même chose en SQL. Apprenez le langage, pas le produit.... Ca ira beaucoup mieux après ! Et vous verrez qu'en moyenne vous développerez 10 à 20 % plus rapidement qu'avec le PL/SQL d'Oracle !

Mon livre, comme mon site web peuvent vous y aider : http://sqlpro.developpez.com/booksql05/

A +

[cmako]

Par rapport à quoi ???

Oracle

Par nature les curseurs sont beaucoup plus lent que les requêtes. Les curseurs rendent le code itératif. Or un SGBDR est par nature ensembliste. Utiliser des curseurs pour des traitements est donc stupide, d'autant qu'il y a aujourd'hui toutes les techniques possible pour éviter 100% des curseurs !

Je suis entièrement d'accord que c'est moins performant etc. mais c'est plus facile à déboguer et à entretenir. Par contre lorsque le chargement de la base plante par exemple pour une violation de PK, avec un curseur on peut tout de suite afficher la ligne qui pose le problème.

Cela n'existe pas en SQL. Ce n'est pas parce que Oracle fait n'importe quoi pour éviter SQL et qui plus est franchement pas génial (CONNECT BY, TO_NUMBER, MINUS, =!, DECODE, CREATE SYNONYM....) qu'il faut en imiter ses stupidités. Pour cela MS SQL Server est plus respectueux de la norme SQL. N'oubliez pas que SQL est un langage normatif. Au lieu d'apprendre ORACLE, vous auriez mieux fait d'apprendre le langage SQL. Mon livre, comme mon site web peut vous y aider !

Bon alors là, si on commence a rentrer sur le perpétuel débat entre SQL server et Oracle on a pas fini. SQL Server prend aussi les libertés par rapport à la norme SQL.

N'étant spécialiste des bases de données que depuis 20 ans, je ne connais pas les transactions autonomes... Pourriez vous m'en dire plus sur ce concept ?

http://www.aide-oracle.net/2009/06/a...autonomes.html
C'est très pratique.

Encore une fois votre méconnaissance du langage SQL vous fait dire des bêtises. Voir la réponse que j'ai apporté ici :
http://www.developpez.net/forums/d69...t/#post4425537

J'ai répondu.

Il est dommage d'avoir appris à conduire une twingo. Il aurait été plus intelligent d'apprendre à conduire une voiture ! C'est la même chose en SQL. Apprenez le langage, pas le produit.... Ca ira beaucoup mieux après ! Et vous verrez qu'en moyenne vous développerez 10 à 20 % plus rapidement qu'avec le PL/SQL d'Oracle !

Alors LA!! C'est Oracle qui est comparé à twingo?
Si je poste ce message dans le forum Oracle, je suis sûr que ça va bombarder de messages.

(Mais en pratique, une twingo c'est bien pour commencer à conduire )

Encore une fois, je connais le langage SQL, mais Oracle nous offre beaucoup plus de choix en développement.
Si je choisis les curseurs ce n'est pas par ce que je ne sais pas utiliser SQL mais pour des questions de lisibilité et de maintenance.

[mikedavem]

Si je choisis les curseurs ce n'est pas par ce que je ne sais pas utiliser SQL mais pour des questions de lisibilité et de maintenance

Je ne suis pas là pour faire la guerre à qui que ce soit mais je ne suis pas tout à fait d'accord avec vous sur ce point.

Le langage SQL est de par nature ensembliste et est beaucoup plus performant utilisé tel quel. J'ai encore eu le cas récemment ou il a fallu revoir une procédure stockée à base de curseur avec des performances lamentables (Vous savez les utilisateurs qui vous disent .... oh j'appuie sur le bouton et c'est long pour afficher, franchement c long votre truc .....).

Il a simplement suffit de remplacer les curseurs par un simple code ensembliste pour résoudre le problème.

++

[SQLpro]

http://www.aide-oracle.net/2009/06/a...autonomes.html
C'est très pratique.

Sauf que c'est TOUT sauf une transaction. Et comme c'est parfaitement stupide et totalement hors norme, je ne peut que désapprouver car cela viole les règles fondamentale du principe même des transactions !

Encore une fois, apprenez les bases de données et le langage SQL et non pas un produit, vous serez plus à l'aise et moins grincheux !

Si je choisis les curseurs ce n'est pas par ce que je ne sais pas utiliser SQL mais pour des questions de lisibilité et de maintenance

On en reparlera quand vous commencerez à avoir un peu de volume dans vos données. C'est mon pain quotidien que de redresser les performances lamentable des mecs qui développent avec les pieds en SQL !!! Et je me fait payer 1200 € HT/jour...

A +

A +

[elsuket]

Si je choisis les curseurs ce n'est pas par ce que je ne sais pas utiliser SQL mais pour des questions de lisibilité et de maintenance.

C'est vrai, un gros curseur bien dégueulasse de 100 lignes avec 50 variables, c'est bien plus lisible et maintenable qu'une requête

Pour info.

Les transactions autonomes, ça c'est ACID

Bon boulot,

@++

[cmako]

Sauf que c'est TOUT sauf une transaction. Et comme c'est parfaitement stupide et totalement hors norme, je ne peut que désapprouver car cela viole les règles fondamentale du principe même des transactions !

Non, pas du tout! Je ne suis pas du tout d'accord que chez Oracle ils s'amusent de faire des choses complètement absurdes et stupides.
Oracle est une base transactionnelle dès le début (alors que en SQL Server il faut demander explicitement BEGIN TRAN).
C'est bel et bien une transaction et l'exemple donné est bien parlant.

On en reparlera quand vous commencerez à avoir un peu de volume dans vos données. C'est mon pain quotidien que de redresser les performances lamentable des mecs qui développent avec les pieds en SQL !!! Et je me fait payer 1200 € HT/jour...

Je sais très bien que ce n'est pas aussi performant. Le chargement initial est effectivement est très lent, mais le chargement quotidien est correct et l'avantage c'est que le code est clair et possible de déboguer.

[mikedavem]

Oracle est une base transactionnelle dès le début (alors que en SQL Server il faut demander explicitement BEGIN TRAN).
C'est bel et bien une transaction et l'exemple donné est bien parlant.
.

SQL Server est une base transactionnelle dès le début également sauf que le moteur supporte 3 modes de transactions dont le mode autocommit qui est le mode par défaut :

Une transaction est automatiquement validée une fois terminée. Si une erreur se produit la transaction est invalidée. (On parle quand même bien de transaction)

Je sais très bien que ce n'est pas aussi performant. Le chargement initial est effectivement est très lent, mais le chargement quotidien est correct et l'avantage c'est que le code est clair et possible de déboguer.

Je n'en doute pas une seconde dans votre cas mais j'émets une forte réserve dans le cas d'une VLDB à forte occupation transactionnelle

++