IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

NoSQL Discussion :

Questionnement sur NoSQL


Sujet :

NoSQL

  1. #1
    Membre éclairé
    Homme Profil pro
    Chef de projet
    Inscrit en
    Mars 2017
    Messages
    323
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chef de projet
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2017
    Messages : 323
    Points : 781
    Points
    781
    Par défaut Questionnement sur NoSQL
    Bonjour,

    je planche sur un nouveau projet censé stocker des données (comme beaucoup de projets ) et j'ai eu une proposition par un presta d'utiliser une base NoSQL (MongoDB en l'espèce, mais c'est pas le point le plus important).
    N'ayant aucune connaissance en NoSQL, je me suis documenté sur le sujet, et la première chose qui me frappe c'est que ici https://fr.wikipedia.org/wiki/MongoDB il est écrit "ne nécessitant pas de schéma prédéfini des données". Dans toutes les lectures que j'ai eu, l'idée générale que j'en sortais c'est que si on veut pas trop se prendre la tête avec les schémas et la normalisation tout en ayant une scalabilité facile -> NoSQL. Or je me dis qu'il y a un truc, sinon le monde entier serait déjà en NoSQL.

    Etant depuis toujours dans les applis de gestion et les bases SQL relationnelles (je suis dev à la base, pas DBA), cette mouvance est un nouveau paradigme pour moi. Et j'admets que sans typage des données, sans structure définie, cette base NoSQL serait quoi? Un gros tableau associatif, un sac fourre tout dans lequel je mets tout? Mais comment puis je m'assurer par exemple qu'on ne pourrait pas supprimer un client qui possède des factures?

    C'est assez abstrait, et j'ai du mal à me représenter en quoi c'est aussi génial qu'on me le dis. Et surtout, dans des applications devant respecter des contraintes d'intégrité des données, je ne vois pas comment le NoSQL va se débrouiller pour le faire. Or si ce presta s'en sert habituellement, j'imagine qu'il ne met pas à la poubelle l'intégrité, ca serait un peu gros.

    Si quelques un d'entre vous ont des éclairages à ce sujet...merci

  2. #2
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    Bonjour,

    Lorsque l'on aborde le monde du NoSQL, et aussi celui du Big Data, il faut justement mettre de côté, je dirais même oublier, tout ce que l'on connaît du monde du SGBDR, monde qui est familier à tant de personnes.



    Les bases de données relationnelles existent depuis la fin des années 70, donc depuis plus de 40 ans. Elles ont amené avec elles :
    - une modélisation (entre autre Merise avec un MCD et un MPD)
    - un typage fort des données
    - une gestion de données structurées, en lignes et en colonnes (on appelle cela aussi des données tabulaires)
    - un stockage des données en ligne dans les fichiers de la base de données
    - une normalisation forte
    - des contraintes d'unicité et d'intégrité référentielle
    - un moteur transactionnel
    - des propriété ACID

    Elles sont utilisées dans le monde de l'OLTP, du Datawarehouse et du Datamart.



    Les SGBDR sont des logiciels qui s'exécutent sur une seule machine où la scalabilité verticale a toujours été de mise dès qu'il fallait ajouter de la ressource matérielle (mémoire ou CPU).

    Certes, il y a bien quelques exceptions comme le cluster Oracle RAC qui fonctionne sur un ensemble de machines, mais les ressources (mémoire et disque) sont partagées, ce qui ne sera pas le cas des clusters en NoSQL et Big Data où les noeuds du cluster ne partagent rien (architecture Shared-Nothing).

    Ce sont toutes ces caractéristiques qui ont donné leurs forces aux SGBDR, mais aussi leurs faiblesses (je devrais plutôt dire leurs limites).



    L'avènement du Web au début des années 2000, les réseaux sociaux, les smartphones, les emails, l'internet des objets (IoT)..., bref tous ces canaux de diffusion d'informations diverses sont à l'origine de ce que l'on a appelé un déluge de données.

    Et ce volume vertigineux de données n'a pu être collecté, stocké, géré, analysé et exploité par les solutions informatiques de l'époque, les SGBDR étant même incapables de répondre à cette fameuse problématique des 3V (Volume, Vélocité et Variété) issue du monde du Big Data.

  3. #3
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    Pour répondre à cette problématique des 3V, on a du tout réinventer.

    En particulier, voici ce qui a été mis en place (attention, il s'agit de grandes généralités sur le NoSQL et le Big Data, et il existe bien entendu des exceptions) :

    - on ne travaille plus sur une seule machine, mais sur un ensemble de machines (nœuds) qui travaillent de concert et qui forment un cluster

    - les données, provenant de l'extérieur et qui sont ingérées par des solutions de type NoSQL et Big Data, sont distribuées sur les différents nœuds du cluster. On va ainsi pouvoir paralléliser les traitements, et comme les nœuds ne partagent rien (ni CPU, ni RAM à cause de l'architecture Shared-Nothing), il est facile de rajouter des nœuds pour avoir plus de puissance (scalabilité horizontale)

    - on traite de la donnée en masse, et l'on se moque donc des problématiques de cohérence, d'intégrité et de qualité des données. Tout cela doit être vu (si nécessaire) en amont, dans les systèmes qui sont à l'origine de l'information

    - le fait de traiter de la données en masse implique aussi que l'on n'a pas besoin de moteur transactionnel, ni de schéma de données. Car le principe est plutôt de faire du WORM (Write Once / Read Many) : on écrit une fois l'information qui est immuable, et on l'exploite plusieurs fois. Comme il n'y a pas de schéma, l'insertion de données ne pose en général pas de problème. C'est à la lecture que les problèmes seront éventuellement rencontrés, lorsque l'on voudra lire par exemple une clé dans un document JSON, clé qui n'existe pas

    - l'information étant plutôt immuable, on n'a pas de mise à jour. Si ce besoin persiste, on a plutôt tendance à ne pas faire une mise à jour, mais on insère la nouvelle donnée, et on historise (versionne) l'ancienne donnée

    - on exécute des requêtes et des calculs de type analytiques, qui portent non plus sur l'intégralité des données d'une ligne, mais sur quelques colonnes qui ont un sens métier, d'où le stockage de données en colonnes, et non plus en ligne

    - les bases NoSQL ne sont pas faites pour faire des jointures. Au contraire, on dénormalise à fond, et on n'hésite pas à répéter l'information (tout le contraire des SGBDR donc)


    Tout ceci ne constitue que des grandes généralités.

    En ce qui concerne le NoSQL, pour répondre aux différents besoins (use cases), on a inventé 4 grands types de bases NoSQL :

    - orientées clé / valeur, comme Redis. Souvent utilisées avec les sites web de e-commerce où la clé représente l'ID de session de l'internaute, et la valeur est un champ géré par l'application (pas par la base) et qui peut être la sérialisation des articles issus du panier de l'internaute

    - orientées documents, comme CouchBase ou Mongo. Par document, on entend des données au format XML, mais surtout JSON car elles prennent moins de place

    - orientées colonnes, comme Cassandra (ou HBase mais sur un cluster Hadoop), pour faire des requêtes analytiques

    - orientées graphes, comme Neo4J. Ce type de bases gère un graphe qui est un ensemble de nœuds reliés par des relations qui ont une direction. Un exemple simple est de sniffer le réseau informatique, et d'importer le fichier de Log dans la base graphe. Un premier type de nœuds représentera les machines avec leurs IP, et un second type les ports utilisés.
    On aura un premier type de relation entre les machines et leurs ports d'écoute, et un second type de relation d'un port d'une machine à un autre port pour symboliser les paquets réseau. Il est alors possible d'interroger la base pour obtenir par exemple le Top 10 des 10 machines qui supportent le plus de trafic.

  4. #4
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    Pour revenir à la question d'origine, je ne peux y répondre que partiellement, car je n'ai pratiqué MongoDB qu'en version 3 en 2016, sachant que l'on en est à la version 5.

    Et donc à cette époque, dans MongoDB, il n'y avait pas de contraintes d'unicité, pas de contrainte d'intégrité référentielle, pas de moteur transactionnel, pas de jointure, et on dénormalisait les données au sein des documents JSON.

    Tout ce que je sais, c'est que dans la version 4, ils ont introduit les transactions, mais je n'ai aucune expérience.

    Pour se former sur MongoDB, il y a des cours gratuits sur MongoDB University :
    https://university.mongodb.com/

  5. #5
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    Pour finir, 2 informations :

    1) même si les SGBDR et le NoSQL sont 2 mondes qui différent, il existe cependant une certaine convergence.

    Par exemple, comme on l'a vu, certaines bases de données NoSQL (comme MongoDB) ont implémenté un moteur transactionnel.

    Et des bases relationnelles, comme Oracle, qui ne géraient à l'époque que des tables, donc des données structurées, se sont mises à gérer du XML et du JSON, donc des données semi-structurées.

    Oracle s'est aussi mis à implémenter sur sa base de données relationnelle le Sharding.



    2) pour les amateurs de théorie, il existe le théorème de Brewer, encore appelé théorème de CAP (Coherence, Availability, Partition Tolerance).

    Selon ce théorème (source Wikipédia), il est dit qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps (c'est-à-dire de manière synchrone) les trois contraintes suivantes :

    - Cohérence (Consistency en anglais) : tous les nœuds du système voient exactement les mêmes données au même moment

    - Disponibilité (Availability en anglais) : garantie que toutes les requêtes reçoivent une réponse

    - Tolérance au partitionnement (Partition Tolerance en anglais) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome)



    Ce théorème est un des grands arguments des défenseurs des bases de données de type NoSQL qui préfèrent généralement la disponibilité des données. À l’inverse, les bases de données relationnelles privilégient, via les contraintes d’intégrité ACID, la cohérence des données.

    Faut vraiment aimer la théorie...

  6. #6
    Membre éclairé
    Homme Profil pro
    Chef de projet
    Inscrit en
    Mars 2017
    Messages
    323
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chef de projet
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2017
    Messages : 323
    Points : 781
    Points
    781
    Par défaut
    Merci pour cette réponse très complète que j'ai du relire plusieurs fois. Effectivement, c'est une toute autre façon d'aborder le stockage de données. Ca me fait penser à l'object storage sur lequel je travaille en ce moment, via celui d'OVH, ou le but est clairement le stockage en masse d'objets quelconques, on en a besoin pour stocker du pdf et du log.
    Mais ces 2 types de données se prêtent bien à ça, or j'avoue que pour une appli de gestion, je ne vois pas comment se passer du typage et de la structuration de la donnée. On a quand même besoin d'assurer des cohérences que le NoSQL ne permettra pas, ou pas facilement, et sur des données qui seront pas forcément write once, read many. On va faire de l'update aussi.

    Je ne dis pas que le NoSQL ne nous servira pas notamment sur la partie stockage photos, l'object storage se prêtant aussi très bien à ça et étant je pense supporté par du NoSQL, ou pouvant l'être en tout cas car ce que je lis colle à ce use case, mais le reste de l'app ne me parait pas viable sur du NoSQL.

    Je pense que je vais chercher des exemples d'app avec la base associée pour être devant la pratique: y'a quoi dans une base comme ça, comment elle fait pour fonctionner, car je pense qu'il doit exister des apps de gestion qui s'en servent, si le presta nous le propose c'est qu'il doit savoir faire. Mais je tiens quand même à mettre les mains sous le capot...

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par rouardg Voir le message
    ...

    Certes, il y a bien quelques exceptions comme le cluster Oracle RAC qui fonctionne sur un ensemble de machines, mais les ressources (mémoire et disque) sont partagées, ce qui ne sera pas le cas des clusters en NoSQL et Big Data où les noeuds du cluster ne partagent rien (architecture Shared-Nothing).

    Ce sont toutes ces caractéristiques qui ont donné leurs forces aux SGBDR, mais aussi leurs faiblesses (je devrais plutôt dire leurs limites).
    Il y a aussi les bases de données fédérés via les vues partitionnées distribuées de Microsoft SQL Server qui est en totalité une architecture Shared-Nothing utilisés notamment dans pas mal de site web marchent à forte volumétrie/concurrence come fnac.com...

    Citation Envoyé par rouardg Voir le message
    ...
    L'avènement du Web au début des années 2000, les réseaux sociaux, les smartphones, les emails, l'internet des objets (IoT)..., bref tous ces canaux de diffusion d'informations diverses sont à l'origine de ce que l'on a appelé un déluge de données.

    Et ce volume vertigineux de données n'a pu être collecté, stocké, géré, analysé et exploité par les solutions informatiques de l'époque, les SGBDR étant même incapables de répondre à cette fameuse problématique des 3V (Volume, Vélocité et Variété) issue du monde du Big Data.
    Sauf que la plupart des grand SGBD relationnels comme Oracle ou SQL Server intègrent désormais des techniques NoSQL... Par exemple pour MS SQL Server il est possible de faire des bases DocumentDB, Big Table, Graph ou bien Columstore/In Memory (Vertical, pour les tables de type paires clés/valeur par exemple) tout en bénéficiant du monde relationnel... Et cela au même prix de licence (contrairement à Oracle ou tout module supplémentaire est payant...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par kunnskap Voir le message
    ...Ca me fait penser à l'object storage sur lequel je travaille en ce moment, via celui d'OVH, ou le but est clairement le stockage en masse d'objets quelconques, on en a besoin pour stocker du pdf et du log.
    Pour le DcumentDB, Microsoft SQL Server est en pointe depuis 16 ans avec le concept de FILESTREAM qui permet de stocker des fichiers de toute nature dans le système de fichiers mais sous le contrôle du SGBDR y compris de manière transactionné ou lors des sauvegardes/restauration... Actuellement aucun produit ne propose un système équivalent, que la norme SQL avait prévu en 1999 avec le concept de DATALINK...

    Mais ces 2 types de données se prêtent bien à ça, or j'avoue que pour une appli de gestion, je ne vois pas comment se passer du typage et de la structuration de la donnée. On a quand même besoin d'assurer des cohérences que le NoSQL ne permettra pas, ou pas facilement, et sur des données qui seront pas forcément write once, read many. On va faire de l'update aussi.

    Je ne dis pas que le NoSQL ne nous servira pas notamment sur la partie stockage photos, l'object storage se prêtant aussi très bien à ça et étant je pense supporté par du NoSQL, ou pouvant l'être en tout cas car ce que je lis colle à ce use case, mais le reste de l'app ne me parait pas viable sur du NoSQL.

    Je pense que je vais chercher des exemples d'app avec la base associée pour être devant la pratique: y'a quoi dans une base comme ça, comment elle fait pour fonctionner, car je pense qu'il doit exister des apps de gestion qui s'en servent, si le presta nous le propose c'est qu'il doit savoir faire. Mais je tiens quand même à mettre les mains sous le capot...
    Pour information, EDF stocke les photos des panneaux solaire PHOTOWATT en grande résolution dans du FILESTREAM associé à une base MS SQL Server. La partie photo représentant plus de 99% du volume des données (plusieurs To).

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par rouardg Voir le message
    ;;;2) pour les amateurs de théorie, il existe le théorème de Brewer, encore appelé théorème de CAP (Coherence, Availability, Partition Tolerance).

    Selon ce théorème (source Wikipédia), il est dit qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps (c'est-à-dire de manière synchrone) les trois contraintes suivantes :

    - Cohérence (Consistency en anglais) : tous les nœuds du système voient exactement les mêmes données au même moment

    - Disponibilité (Availability en anglais) : garantie que toutes les requêtes reçoivent une réponse

    - Tolérance au partitionnement (Partition Tolerance en anglais) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome)



    Ce théorème est un des grands arguments des défenseurs des bases de données de type NoSQL qui préfèrent généralement la disponibilité des données. À l’inverse, les bases de données relationnelles privilégient, via les contraintes d’intégrité ACID, la cohérence des données.

    Faut vraiment aimer la théorie...
    Ce théorème a été utilisé à la manière d'une arnaque par les tenant du NoSQL afin de combattre les SGBDR. Et toi aussi tu es tombé de le panneau... En effet le CAP existe dans les SGBD Relationnel depuis des années... Le théorème ne démontre que le fait que ces 3 fonctionnalités ne peuvent jamais être synchrone, quelque soit le type de SGBD !
    Les tenant du NoSQL avait sciemment oublié le terme "synchrone" disant que les SGBDR étaient incapable de tenir les 3 fonctionnalités !!!

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  10. #10
    Membre éclairé
    Homme Profil pro
    Chef de projet
    Inscrit en
    Mars 2017
    Messages
    323
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chef de projet
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2017
    Messages : 323
    Points : 781
    Points
    781
    Par défaut
    Merci pour vos réponses.
    Le choix de SQL Server serait donc une possible ouverture vers du NoSQL que SQL Server implémente quand même, plutôt que directement utiliser du NoSQL. Qui me semble peu coller au besoin général, mais on va en discuter avec le presta...

  11. #11
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Oui, d'autant que c'est notablement moins cher que Oracle.
    Il y a même une version Web (mode locatif uniquement) très peu couteuse (moins de 100 € par mois). Certes limitée, mais il y a de nombreuses éditions qui permettent la "scalability", et le fait de passer de l'une à l'autre peu se faire en quelques secondes d’interruption avec 2 commandes SQL (EXEC sp_detach_db / CREATE DATABASE ... FOR ATTACH ...) quelque soit la volumétrie de la base et au mieux sans aucune interruption via le mirroring ou ALwaysOn...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [HTML] Questionnement sur le CID(Content ID)
    Par lurked dans le forum Balisage (X)HTML et validation W3C
    Réponses: 5
    Dernier message: 07/02/2008, 20h34
  2. Questionnement sur une migration MsSQL > PostGreSQL
    Par Jsh dans le forum PostgreSQL
    Réponses: 3
    Dernier message: 03/10/2007, 10h36
  3. Réponses: 1
    Dernier message: 26/09/2007, 23h22
  4. Questionnement sur "virtual"
    Par monstroplante dans le forum C#
    Réponses: 4
    Dernier message: 03/04/2007, 12h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo