Est-il profitable de créer les index simples sur les colonnes des dimensions ? Afin de rentrer dans les détails je vous propose faire quelques tests simples.

Les particularités

Pour utiliser N index de la même table dans la même requête le moteur doit confronter (l'intersection en cas "AND") les N sous-ensembles au moyen de "Merge Join" (le coût O(n) environ), "Hash Match" (le coût O(n * log2 n) environ) ou une autre méthode i.e. "Bitmap".

Les particularités d'OLAP (relationnel) :

Les séquences (compteurs) sont introduits en 2012. Par contre, pour les anciennes versions il vous faut les implémenter.

Implémentation 1

Avantages: une tables pour toutes les séquences
Désavantages: pour éviter les verrouillages lors d'insertions intensives depuis les connexions simultanées il faut l’appeler hors de la transaction

Quelques épisodes de la vie NoSQL vue par YesSQL.

Ce sujet a été monté lors de la validation technique d'un projet. Le scénario des tests est :

• estimer l'insertion intensive des données depuis les nombreuses unités (par exemple, les capteurs)
• comparer la simplicité et la performance des requêtes « typiques »

Le test d'insertion, ou l'Expulsion du Paradis

J'ai limité l'insertion des données depuis les multiples capteurs par 10 millions lignes ce que est corresponde à 1 heure de travail environ.

C'est simple en SQL Server, mais faites-vous l'attention sur les droits de la connexion utilisée.

Comment exporter une ou plusieurs tables dont une colonne a la propriété "identity" avec l’assistant d'export des données (data export wizard) ?

Démarrez l'assistant sur la BDD source et choisissez les paramètres de connexion de BDD SQL Server source et cible.

Notez que les tables cibles ne doivent pas exister dans la BDD cible car nous les créerons lors d'export.