Discussion:Microsoft SQL Server

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

J'ai complété l'article. Mon point de vue est extremement technique. Il serait interressant que quelqu'un donne des explications plus pratiques. Il manque une partie sur les cubes OLAP que je ne peux pas traiter mais qui peut être traitée dans un article à part compte tenu du fait qu'ils existent aussi dans d'autres bases de données (Oracle par exemple).

Enfin, bien sûr, cette article a besoin d'une bonne relecture.

--Olivier "Warny" Marty 30 octobre 2005 à 11:14 (CET)[répondre]

J'ai réintegré mon texte sur les index que j'ai complété. Le texte de remplacement parlait d'enregistrements séquentiels. En fait, ceux-ci, sur une grande quantité de données seraient beaucoup trop lent à manipuler. Comme les bloc de données ne sont pas séquentiels, une recherche sur un millions d'enregistrement prend plusieurs secondes (testé - il suffit de faire des calculs sur une table sans index). Il faut donc une organisation beaucoup plus efficace et l'intégration de précalculs.

Olivier "Warny" Marty 3 décembre 2005 à 19:39 (CET)[répondre]



Ceux qui sont au courant pourraient peut-être expliquer la politique de licence : 1 proc dual core = 1 seule licence (ça je sais) mais pour le reste, l'histoire des nombres d'utilisateurs, quand a t'on besoin d'une licence par processeur ... ? Exemple type : on monte un serveur web (asp + SQL Server par exemple) : le site est accédé par des milliers de personnes mais 1 seule connex entre asp et SQL Server est utilisée... quel type de licence faut-il ?Commons:

J'ai répondu à cette question. Dites-moi si le texte est assez clair, et s'il apporte la bonne réponse pour les applis web (licence par processeur). Soit dit en passant, comme un jeu de recordset se traduit par une connexion, on a facilement un dizaine de connexions simultanées sur un serveur web et non une seule. Olivier "Warny" Marty 23 mars 2006 à 22:54 (CET)[répondre]

Compilation des vues[modifier le code]

Petit commentaire sur les vues, une vues n'est pas compilée en tant que tel c'est uniquement une requête nommé. Quand SQL Server execute une requête et que celle-ci se base sur des vues, il se produit un phénomène appelé EXPAND, SQl Server remplace le nom de la vue par sa définition, il fait de même pour toutes les autres y compris les vues imbriquées. Si compilation il y a, elle ne se produit qu'après donc au niveau de la requête et pas au niveau de la vue.

Ceci pour expliquer mes 2 modifs à la sections des vues.

Vérouillage niveau ligne[modifier le code]

J'ai indiqué dans l'article que le vérouillage niveau ligne était effectif à partir de la version 2005. J'était persuadé, avant, qu'il était valable à partir de la version 2000. En fait, Microsoft ne communique que très peu sur ce point, c'est le technico-commercial de Microsoft qui m'a donné cette info lors d'une visite pour présenter les produits à sorir début 2005 qui m'avait donné cette information. Je suis tenté de le croire.

SQL Server 2000 supporte le vérouillage de niveau ligne. il existe une directive "ROWLOCK" permettant de forcer au besoin celui-ci.

Je confirme, et amélioration[modifier le code]

le verrouillage de ligne existe depuis au moins la 2000. On peut forcer l'utilisation du ROW locking avec sp_index_option. J'ai fait quelques corrections et améliorations en rajoutant un paragraphe objet et quelques éléments sur l'indexation.

Utilisateur:Sqlpro 28 mai 2009 à 23:59 (CET)[répondre]

Le néophite n'y trouve pas son compte[modifier le code]

J'aurais aimé trouvé une explication au départ du type "à quoi cela sert". Je viens sur Wiki pour savoir ce que c'est pas pour avoir tous les détails techniques. Je veux savoir quelle en est l'utilité, dans quel contexte c'est utile, qui s'en sert, pourquooi !!!

Merci d'ajouter ces données.

Il suffit de lire le premier lien : système de gestion de base de données pour y répondre. JackPotte ($) 27 juillet 2015 à 20:02 (CEST)[répondre]

illustration[modifier le code]

Pourquoi les illustrations que j'avais mis ont-elles disparues (notamment requête parallélisée, management policcies...) ? Vous préférez des articles chiant sans aucune illustration à des articles égayées d'images ? Je ne comprend pas ceux qui détruise le travail des autres. Encore une fois je considère que Wikipedia perd de son mérite lorsque l'on en retire des explication, notamment visuelles ! Serait-ce parce que certains préféraient MySQL ou PostGreSQL ??? Je comprends bien les limites des images : uniquement réservé aux images de logos de marques déposées, de bâtiments récents et de monnaies, mais alors que vient faire l'image du "bateau" SQL Server ? Ce n'est ni un logo, ni un bâtiment récent, ni une monnaie ! De la même façon, que vient faire la "Carte de cas de choléra pendant l'épidémie de 1854 à Londres" de la page https://fr.wikipedia.org/wiki/Analyse_spatiale ???

C'est effectivement dommage mais j'avais tenté de t'avertir sur Commons:User_talk:SQLpro#Images_de_Microsoft_SQL_Server pour les sauvegarder. En effet, la charte de copyright commons:Commons:Fair use/fr explique le principe, et v:Modèle:Capture d'écran Microsoft comment Microsoft peut protéger légalement son image. JackPotte ($) 27 juillet 2015 à 19:59 (CEST)[répondre]

DDL / DCL transactionnel[modifier le code]

"Contrairement à Oracle ou PostGreSQL, SQL Server transactionne même les ordres du DDL (CREATE, ALTER, DROP...) et du DCL (GRANT, REVOKE...)."

=> Cette phrase est VRAIE sur Oracle (commit implicite avant et après chaque ordre DDL/DCL), c'est une des caractéristiques de ce SGBDR.

=> Cette phrase est entièrement FAUSSE sur PostgreSQL où le DDL/DCL est transactionnel. Cause possible de la mauvaise interprétation : un test effectué sans ouvrir de transaction (par exemple avec un psql configuré par défaut). Il suffit pourtant de 5 secondes pour infirmer:

start transaction; drop table t1; rollback; select * from t1; => OK

C'est valable dans toutes les versions supportées de PostgreSQL (en fait toutes les versions).

La page ne mentionne en revanche pas que c'est SQL Server qui a des restrictions sur le DDL/DCL transactionnel avec le verrouillage optimiste, cf https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-3961-database-engine-error?view=sql-server-ver15

"The following DDL statements are not permitted under snapshot isolation after a BEGIN TRANSACTION statement: ALTER TABLE, CREATE INDEX, CREATE XML INDEX, ALTER INDEX, DROP INDEX, DBCC REINDEX, ALTER PARTITION FUNCTION, ALTER PARTITION SCHEME, or any common language runtime (CLR) DDL statement."

Cette phrase "Le niveau d’isolation READ COMMITTED SNAPSHOT opère exactement à la manière d'Oracle ou de PostGreSQL en substituant au niveau d’isolation READ COMMITTED un versionnement des lignes pour un verrouillage optimiste. " est fausse ou incomplète. Non, cela ne fonctionne pas "exactement à la manière de PostgreSQL" puisque, sous SQL Server, ce niveau restreint le DDL/DCL transactionnel, ce qui est apparemment important puisque c'est mentionné comme un avantage à un autre endroit de la page.

Bref, transformer une limitation de SQL Server par rapport à un autre produit comme un avantage, grâce à des erreurs et des omissions, je trouve ça très limite dans un article encyclopédique. — Le message qui précède, non signé, a été déposé par l'IP 92.184.108.180 (discuter), le 15 juillet 2021 à 16:36 (CEST)[répondre]