Besoin de conseils ! Comment réaliser ce genre de base ?
6 réponses
jerome
Salut =E0 tous,
Je veux faire une base de donn=E9es qui contient des contacts. Chacun de=20
ces contacts poss=E8derait des propri=E9t=E9s de base (genre nom, pr=E9nom)=20
mais pourrait en m=EAme temps poss=E9der ces propres propri=E9t=E9s (genre=20
profession, adresse e-mail pour certain, age, sexe pour d'autres) en=20
nombre illimit=E9 et sur diff=E9rents type de donn=E9es (enfin disons bit,=20
smallint, int, float, datetime et varchar suffirait). J'ai bien pens=E9=20
faire un mod=E8le du genre :
tblContacts
IdContact int
strNom varchar(50)
strPrenom varchar(50)
tblProprietes
IdContact int
strNom varchar(50)
strValeur varchar(255)
smlType smallint
o=F9 smlType permettrait de d=E9finir le type de donn=E9es (bit, smallint,=20
int, float, datetime, varchar) sachant qu'ensuite il suffit de caster=20
strValeur en fonction de ce type (puisque que le varchar accepte la=20
convertion vers n'importe lequel de ces types). Ce qui donnerait par=20
exemple (en partant du principe que bit=3D0, smallint=3D1, int=3D2, float=
=3D3,=20
varchar=3D4, datetime=3D5)
tblContacts
IdContact strNom strPrenom
1 Andr=E9 Dupont
2 Eric Marchand
Maintenant outre le fait que je trouve pas =E7a "super propre", je me=20
retrouve bloqu=E9 d=E9s que je veux obtenir tr=E8s rapidement (par exemple=20
pour faire des stats, une recherche ou une simple extraction avanc=E9e=20
de donn=E9es) les propri=E9t=E9s de chaque utilisateur. Je veux =E9viter=20
d'utiliser des proc=E9dures stock=E9es (l'une pour obtenir la liste des=20
utilisateurs, l'autre pour obtenir les propri=E9t=E9s de l'utilisateur en=20
cours) dans ma base j'ai plus de 500000 utilisateurs.
Quelqu'un pourrait me donner des conseils pour r=E9aliser =E7a proprement=20
(sous SQL2000 ou 2005 et avec ADO.net).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
Bonjour,
a écrit :
Salut à tous,
Je veux faire une base de données qui contient des contacts. Chacun de ces contacts possèderait des propriétés de base (genre nom, prénom) mais pourrait en même temps posséder ces propres propriétés (genre profession, adresse e-mail pour certain, age, sexe pour d'autres) en nombre illimité et sur différents type de données (enfin disons bit, smallint, int, float, datetime et varchar suffirait). J'ai bien pensé faire un modèle du genre :
tblContacts IdContact int strNom varchar(50) strPrenom varchar(50)
tblProprietes IdContact int strNom varchar(50) strValeur varchar(255) smlType smallint
où smlType permettrait de définir le type de données (bit, smallint, int, float, datetime, varchar) sachant qu'ensuite il suffit de caster strValeur en fonction de ce type (puisque que le varchar accepte la convertion vers n'importe lequel de ces types). Ce qui donnerait par exemple (en partant du principe que bit=0, smallint=1, int=2, float=3, varchar=4, datetime=5)
tblContacts IdContact strNom strPrenom 1 André Dupont 2 Eric Marchand
Maintenant outre le fait que je trouve pas ça "super propre", je me retrouve bloqué dés que je veux obtenir très rapidement (par exemple pour faire des stats, une recherche ou une simple extraction avancée de données) les propriétés de chaque utilisateur. Je veux éviter d'utiliser des procédures stockées (l'une pour obtenir la liste des utilisateurs, l'autre pour obtenir les propriétés de l'utilisateur en cours) dans ma base j'ai plus de 500000 utilisateurs.
Quelqu'un pourrait me donner des conseils pour réaliser ça proprement (sous SQL2000 ou 2005 et avec ADO.net).
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/modelisation/metadonnees/
A +
Merci
Jérôme
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Bonjour,
jerome@actisens.com a écrit :
Salut à tous,
Je veux faire une base de données qui contient des contacts. Chacun de
ces contacts possèderait des propriétés de base (genre nom, prénom)
mais pourrait en même temps posséder ces propres propriétés (genre
profession, adresse e-mail pour certain, age, sexe pour d'autres) en
nombre illimité et sur différents type de données (enfin disons bit,
smallint, int, float, datetime et varchar suffirait). J'ai bien pensé
faire un modèle du genre :
tblContacts
IdContact int
strNom varchar(50)
strPrenom varchar(50)
tblProprietes
IdContact int
strNom varchar(50)
strValeur varchar(255)
smlType smallint
où smlType permettrait de définir le type de données (bit, smallint,
int, float, datetime, varchar) sachant qu'ensuite il suffit de caster
strValeur en fonction de ce type (puisque que le varchar accepte la
convertion vers n'importe lequel de ces types). Ce qui donnerait par
exemple (en partant du principe que bit=0, smallint=1, int=2, float=3,
varchar=4, datetime=5)
tblContacts
IdContact strNom strPrenom
1 André Dupont
2 Eric Marchand
Maintenant outre le fait que je trouve pas ça "super propre", je me
retrouve bloqué dés que je veux obtenir très rapidement (par exemple
pour faire des stats, une recherche ou une simple extraction avancée
de données) les propriétés de chaque utilisateur. Je veux éviter
d'utiliser des procédures stockées (l'une pour obtenir la liste des
utilisateurs, l'autre pour obtenir les propriétés de l'utilisateur en
cours) dans ma base j'ai plus de 500000 utilisateurs.
Quelqu'un pourrait me donner des conseils pour réaliser ça proprement
(sous SQL2000 ou 2005 et avec ADO.net).
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/modelisation/metadonnees/
A +
Merci
Jérôme
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Je veux faire une base de données qui contient des contacts. Chacun de ces contacts possèderait des propriétés de base (genre nom, prénom) mais pourrait en même temps posséder ces propres propriétés (genre profession, adresse e-mail pour certain, age, sexe pour d'autres) en nombre illimité et sur différents type de données (enfin disons bit, smallint, int, float, datetime et varchar suffirait). J'ai bien pensé faire un modèle du genre :
tblContacts IdContact int strNom varchar(50) strPrenom varchar(50)
tblProprietes IdContact int strNom varchar(50) strValeur varchar(255) smlType smallint
où smlType permettrait de définir le type de données (bit, smallint, int, float, datetime, varchar) sachant qu'ensuite il suffit de caster strValeur en fonction de ce type (puisque que le varchar accepte la convertion vers n'importe lequel de ces types). Ce qui donnerait par exemple (en partant du principe que bit=0, smallint=1, int=2, float=3, varchar=4, datetime=5)
tblContacts IdContact strNom strPrenom 1 André Dupont 2 Eric Marchand
Maintenant outre le fait que je trouve pas ça "super propre", je me retrouve bloqué dés que je veux obtenir très rapidement (par exemple pour faire des stats, une recherche ou une simple extraction avancée de données) les propriétés de chaque utilisateur. Je veux éviter d'utiliser des procédures stockées (l'une pour obtenir la liste des utilisateurs, l'autre pour obtenir les propriétés de l'utilisateur en cours) dans ma base j'ai plus de 500000 utilisateurs.
Quelqu'un pourrait me donner des conseils pour réaliser ça proprement (sous SQL2000 ou 2005 et avec ADO.net).
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/modelisation/metadonnees/
A +
Merci
Jérôme
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
jerome
Bonjour,
Cette modélisation correspond à mon besoin sauf que si je souhaite obtenir toutes les "propriétés" de mes "contacts" je me retrouve avec autant de ligne que de propriétés. N'y a t'il pas un moyen de gérer ces métadonnées en ayant au final qu'une seule ligne ? Avec le nom de la propriété comme nom de colonne ?
Pour être plus explicite :
Si j'ai (en reprenant la base de l'exemple) :
tblContacts IdContact strNom strPrenom 1 Dupont André
SELECT * FROM tblContacts LEFT OUTER JOIN tblValues ON tblValues.IdUser = tblContacts.IdContact LEFT OUTER JOIN tblFields ON tblFields.IdField = tblValues.IdField WHERE tblUsers.IdUser = 1
Cette modélisation correspond à mon besoin sauf que si je souhaite
obtenir toutes les "propriétés" de mes "contacts" je me retrouve avec
autant de ligne que de propriétés. N'y a t'il pas un moyen de gérer
ces métadonnées en ayant au final qu'une seule ligne ? Avec le nom de
la propriété comme nom de colonne ?
Pour être plus explicite :
Si j'ai (en reprenant la base de l'exemple) :
tblContacts
IdContact strNom strPrenom
1 Dupont André
SELECT
*
FROM tblContacts
LEFT OUTER JOIN tblValues ON tblValues.IdUser = tblContacts.IdContact
LEFT OUTER JOIN tblFields ON tblFields.IdField = tblValues.IdField
WHERE
tblUsers.IdUser = 1
Cette modélisation correspond à mon besoin sauf que si je souhaite obtenir toutes les "propriétés" de mes "contacts" je me retrouve avec autant de ligne que de propriétés. N'y a t'il pas un moyen de gérer ces métadonnées en ayant au final qu'une seule ligne ? Avec le nom de la propriété comme nom de colonne ?
Pour être plus explicite :
Si j'ai (en reprenant la base de l'exemple) :
tblContacts IdContact strNom strPrenom 1 Dupont André
SELECT * FROM tblContacts LEFT OUTER JOIN tblValues ON tblValues.IdUser = tblContacts.IdContact LEFT OUTER JOIN tblFields ON tblFields.IdField = tblValues.IdField WHERE tblUsers.IdUser = 1
Je veux faire une base de données qui contient des contacts. Chacun de ces contacts possèderait des propriétés de base (genre nom, prénom) mais pourrait en même temps posséder ces propres propriétés (genre profession, adresse e-mail pour certain, age, sexe pour d'autres) en nombre illimité et sur différents type de données (enfin disons bit, smallint, int, float, datetime et varchar suffirait).
Un intervenant sur ce forum il y a quelques semaines avait une problématique très similaire, et avait adopté l'usage d'un champ XML...
jerome@actisens.com wrote:
Je veux faire une base de données qui contient des contacts. Chacun de
ces contacts possèderait des propriétés de base (genre nom, prénom)
mais pourrait en même temps posséder ces propres propriétés (genre
profession, adresse e-mail pour certain, age, sexe pour d'autres) en
nombre illimité et sur différents type de données (enfin disons bit,
smallint, int, float, datetime et varchar suffirait).
Un intervenant sur ce forum il y a quelques semaines avait une
problématique très similaire, et avait adopté l'usage d'un champ XML...
Je veux faire une base de données qui contient des contacts. Chacun de ces contacts possèderait des propriétés de base (genre nom, prénom) mais pourrait en même temps posséder ces propres propriétés (genre profession, adresse e-mail pour certain, age, sexe pour d'autres) en nombre illimité et sur différents type de données (enfin disons bit, smallint, int, float, datetime et varchar suffirait).
Un intervenant sur ce forum il y a quelques semaines avait une problématique très similaire, et avait adopté l'usage d'un champ XML...
Fred BROUARD
a écrit :
Bonjour,
Cette modélisation correspond à mon besoin sauf que si je souhaite obtenir toutes les "propriétés" de mes "contacts" je me retrouve avec autant de ligne que de propriétés. N'y a t'il pas un moyen de gérer ces métadonnées en ayant au final qu'une seule ligne ? Avec le nom de la propriété comme nom de colonne ?
Pour être plus explicite :
Si j'ai (en reprenant la base de l'exemple) :
tblContacts IdContact strNom strPrenom 1 Dupont André
SELECT * FROM tblContacts LEFT OUTER JOIN tblValues ON tblValues.IdUser = tblContacts.IdContact LEFT OUTER JOIN tblFields ON tblFields.IdField = tblValues.IdField WHERE tblUsers.IdUser = 1
C'est anti relationnel, vous pouvez le faire en SQL mais cela donnera des requêtes très contreperformantes alors qu'avec un minimum de code dans votre application cliente, c'est très facile.
A +
Jérôme
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
jerome@actisens.com a écrit :
Bonjour,
Cette modélisation correspond à mon besoin sauf que si je souhaite
obtenir toutes les "propriétés" de mes "contacts" je me retrouve avec
autant de ligne que de propriétés. N'y a t'il pas un moyen de gérer
ces métadonnées en ayant au final qu'une seule ligne ? Avec le nom de
la propriété comme nom de colonne ?
Pour être plus explicite :
Si j'ai (en reprenant la base de l'exemple) :
tblContacts
IdContact strNom strPrenom
1 Dupont André
SELECT
*
FROM tblContacts
LEFT OUTER JOIN tblValues ON tblValues.IdUser = tblContacts.IdContact
LEFT OUTER JOIN tblFields ON tblFields.IdField = tblValues.IdField
WHERE
tblUsers.IdUser = 1
C'est anti relationnel, vous pouvez le faire en SQL mais cela donnera
des requêtes très contreperformantes alors qu'avec un minimum de code
dans votre application cliente, c'est très facile.
A +
Jérôme
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Cette modélisation correspond à mon besoin sauf que si je souhaite obtenir toutes les "propriétés" de mes "contacts" je me retrouve avec autant de ligne que de propriétés. N'y a t'il pas un moyen de gérer ces métadonnées en ayant au final qu'une seule ligne ? Avec le nom de la propriété comme nom de colonne ?
Pour être plus explicite :
Si j'ai (en reprenant la base de l'exemple) :
tblContacts IdContact strNom strPrenom 1 Dupont André
SELECT * FROM tblContacts LEFT OUTER JOIN tblValues ON tblValues.IdUser = tblContacts.IdContact LEFT OUTER JOIN tblFields ON tblFields.IdField = tblValues.IdField WHERE tblUsers.IdUser = 1
C'est anti relationnel, vous pouvez le faire en SQL mais cela donnera des requêtes très contreperformantes alors qu'avec un minimum de code dans votre application cliente, c'est très facile.
A +
Jérôme
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
jerome
Oui je comprends, et en général j'écoute vos conseils :)
Mais dans ce cas que vaut il mieux ?
- Récupérer le résultat des deux tables dans un DataSet (.net) et jouer avec. - Récupérer le résultat dans une seule table (comme dans l'exemple) e t traiter chaque ligne en tant que propriété.
La 1ère solution me parait plus efficace. Mais est-elle plus rapide ?
En fait dans les deux cas ce qui me dérange c'est le "poids" en mémoire de ces informations qui represénte au minimum 500000 lignes avec 10 à 30 colonnes.
Oui je comprends, et en général j'écoute vos conseils :)
Mais dans ce cas que vaut il mieux ?
- Récupérer le résultat des deux tables dans un DataSet (.net) et
jouer avec.
- Récupérer le résultat dans une seule table (comme dans l'exemple) e t
traiter chaque ligne en tant que propriété.
La 1ère solution me parait plus efficace. Mais est-elle plus rapide ?
En fait dans les deux cas ce qui me dérange c'est le "poids" en
mémoire de ces informations qui represénte au minimum 500000 lignes
avec 10 à 30 colonnes.
Oui je comprends, et en général j'écoute vos conseils :)
Mais dans ce cas que vaut il mieux ?
- Récupérer le résultat des deux tables dans un DataSet (.net) et jouer avec. - Récupérer le résultat dans une seule table (comme dans l'exemple) e t traiter chaque ligne en tant que propriété.
La 1ère solution me parait plus efficace. Mais est-elle plus rapide ?
En fait dans les deux cas ce qui me dérange c'est le "poids" en mémoire de ces informations qui represénte au minimum 500000 lignes avec 10 à 30 colonnes.
Fred BROUARD
a écrit :
Oui je comprends, et en général j'écoute vos conseils :)
Mais dans ce cas que vaut il mieux ?
- Récupérer le résultat des deux tables dans un DataSet (.net) et jouer avec. - Récupérer le résultat dans une seule table (comme dans l'exemple) et traiter chaque ligne en tant que propriété.
La 1ère solution me parait plus efficace. Mais est-elle plus rapide ?
En fait dans les deux cas ce qui me dérange c'est le "poids" en mémoire de ces informations qui represénte au minimum 500000 lignes avec 10 à 30 colonnes.
analysez les statistiques d'exécution et en premier les IO, en second (si équivalent en IO) la consommation CPU.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
jerome@actisens.com a écrit :
Oui je comprends, et en général j'écoute vos conseils :)
Mais dans ce cas que vaut il mieux ?
- Récupérer le résultat des deux tables dans un DataSet (.net) et
jouer avec.
- Récupérer le résultat dans une seule table (comme dans l'exemple) et
traiter chaque ligne en tant que propriété.
La 1ère solution me parait plus efficace. Mais est-elle plus rapide ?
En fait dans les deux cas ce qui me dérange c'est le "poids" en
mémoire de ces informations qui represénte au minimum 500000 lignes
avec 10 à 30 colonnes.
analysez les statistiques d'exécution et en premier les IO, en second
(si équivalent en IO) la consommation CPU.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Oui je comprends, et en général j'écoute vos conseils :)
Mais dans ce cas que vaut il mieux ?
- Récupérer le résultat des deux tables dans un DataSet (.net) et jouer avec. - Récupérer le résultat dans une seule table (comme dans l'exemple) et traiter chaque ligne en tant que propriété.
La 1ère solution me parait plus efficace. Mais est-elle plus rapide ?
En fait dans les deux cas ce qui me dérange c'est le "poids" en mémoire de ces informations qui represénte au minimum 500000 lignes avec 10 à 30 colonnes.
analysez les statistiques d'exécution et en premier les IO, en second (si équivalent en IO) la consommation CPU.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************