Conseils sur accès aux données
Résolu
mdemo
Messages postés
90
Date d'inscription
mardi 21 mars 2006
Statut
Membre
Dernière intervention
10 mai 2010
-
29 août 2006 à 10:28
cs_skweeky Messages postés 259 Date d'inscription mercredi 3 mai 2006 Statut Membre Dernière intervention 11 janvier 2010 - 7 sept. 2006 à 15:40
cs_skweeky Messages postés 259 Date d'inscription mercredi 3 mai 2006 Statut Membre Dernière intervention 11 janvier 2010 - 7 sept. 2006 à 15:40
A voir également:
- Conseils sur accès aux données
- Récupérer données json (javascript) - Conseils pratiques -Javascript
- Base de données javascript - Conseils pratiques -Javascript
- Chargement de données - Forum C
- La conversion d'un type de données varchar en type de données datetime a créé une valeur hors limites - Forum C# / .NET
- Les données en arabe ✓ - Forum PHP
14 réponses
cs_Yopyop
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
30 août 2006 à 18:35
30 août 2006 à 18:35
re,
Demande quand même l'avis de quelqu'un d'autre (2 avis valent mieux qu'un) car personnellement je ne suis pas passé à ASP.net 2.0.
Mais expérience faite, les solutions "clé en main" de Microsoft sont souvent pratiques pour des choses "simples", mais pas facilement adaptables ou pas optimisées (ex: datagrid, dataset, viewstate, system.directoryservices, ...) .
Perso, je préfère passer 5 jours à me documenter sur la meilleure façon de faire puis implémenter plutôt que d'y aller tête baissée avec les infos de Microsoft (nous travaillons souvent avec des consultants de Microsoft et eux même avouent ne pas aimer certains de leurs outils/framework).
Bonne chance
yopyop
Demande quand même l'avis de quelqu'un d'autre (2 avis valent mieux qu'un) car personnellement je ne suis pas passé à ASP.net 2.0.
Mais expérience faite, les solutions "clé en main" de Microsoft sont souvent pratiques pour des choses "simples", mais pas facilement adaptables ou pas optimisées (ex: datagrid, dataset, viewstate, system.directoryservices, ...) .
Perso, je préfère passer 5 jours à me documenter sur la meilleure façon de faire puis implémenter plutôt que d'y aller tête baissée avec les infos de Microsoft (nous travaillons souvent avec des consultants de Microsoft et eux même avouent ne pas aimer certains de leurs outils/framework).
Bonne chance
yopyop
cs_Yopyop
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
29 août 2006 à 11:30
29 août 2006 à 11:30
re,
je te conseille de créer un répertoire d'upload en dehors du répertoire de ton application (en effet, modifier le répertoire de l'applcation peut provoquer un restart de celle-ci).
Ensuite tu crées un share sur ce répertoire et tu donnes les droits nécessaires (create, delete, ...) à asp_net.
De cette manière, si un jour tu dois déplacer les fichiers (sur un autre disque/machine), normalement tu n'auras qu'à modifier le share pour qu'il pointe sur le nouveau folder (machine).
mais c'est mon point de vue ...
yopyop
je te conseille de créer un répertoire d'upload en dehors du répertoire de ton application (en effet, modifier le répertoire de l'applcation peut provoquer un restart de celle-ci).
Ensuite tu crées un share sur ce répertoire et tu donnes les droits nécessaires (create, delete, ...) à asp_net.
De cette manière, si un jour tu dois déplacer les fichiers (sur un autre disque/machine), normalement tu n'auras qu'à modifier le share pour qu'il pointe sur le nouveau folder (machine).
mais c'est mon point de vue ...
yopyop
mdemo
Messages postés
90
Date d'inscription
mardi 21 mars 2006
Statut
Membre
Dernière intervention
10 mai 2010
29 août 2006 à 13:34
29 août 2006 à 13:34
Merci yopyop pour ta réponse.
Tu as soulevé un point que je ne savais pas: le restarst si on bouge le répertoire.
Par contre comment gères-tu l'accés aux données dans le cas où celles-ci ne sont pas dans le répertoire de l'application ? Faut-il nécessairement avoir un chemin absolu ?
Mon idée initiale était plutôt de garder le disque initial avec ses données, sous l'application ou non suivant ton conseil, et de pouvoir étendre la sauvegarde vers un autre disque si nécessaire. En gros ne pas être limité par mon choix de premier disque, mais pas nécessairement tout basculer vers un plus gros car à terme ça ne pourra pas aller. Il y aurait donc des données par exemple sur deux disques, mais une même base sql pour y accéder et des contrôles serveurs identiques. Dans un premier temps avec un chemin relatif les contrôles vont lire les données sans pb, et seule la sauvegarde du nom de fichier me suffit dans ma base. Si ensuite je dois passer sur un autre disque, un autre serveur, je me dis que le fichier seul ne suffit plus et qu'il faudrait peut être que j'anticipe en ajoutant un champ dans ma base avec le chemin absolu. Je peux reconstruire ainsi le chemin absolu vers différents disques si nécessaire, et si les données doivent bouger il me suffit alors de changer ce champ. Est-ce stupide ou non ? N'y-a-t-il pas un meilleure solution (notamment au niveau du paramétrage du serveur ?
Merci
Tu as soulevé un point que je ne savais pas: le restarst si on bouge le répertoire.
Par contre comment gères-tu l'accés aux données dans le cas où celles-ci ne sont pas dans le répertoire de l'application ? Faut-il nécessairement avoir un chemin absolu ?
Mon idée initiale était plutôt de garder le disque initial avec ses données, sous l'application ou non suivant ton conseil, et de pouvoir étendre la sauvegarde vers un autre disque si nécessaire. En gros ne pas être limité par mon choix de premier disque, mais pas nécessairement tout basculer vers un plus gros car à terme ça ne pourra pas aller. Il y aurait donc des données par exemple sur deux disques, mais une même base sql pour y accéder et des contrôles serveurs identiques. Dans un premier temps avec un chemin relatif les contrôles vont lire les données sans pb, et seule la sauvegarde du nom de fichier me suffit dans ma base. Si ensuite je dois passer sur un autre disque, un autre serveur, je me dis que le fichier seul ne suffit plus et qu'il faudrait peut être que j'anticipe en ajoutant un champ dans ma base avec le chemin absolu. Je peux reconstruire ainsi le chemin absolu vers différents disques si nécessaire, et si les données doivent bouger il me suffit alors de changer ce champ. Est-ce stupide ou non ? N'y-a-t-il pas un meilleure solution (notamment au niveau du paramétrage du serveur ?
Merci
cs_Yopyop
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
29 août 2006 à 16:09
29 août 2006 à 16:09
re,
comme tu l'as dit, ta solution nécessite d'avoir le chemin complet du fichier dans la base. donc si un jour tu changes ton répertoire, cela risque de compliquer les choses (même si le chemin et le filename sont dans 2 champs séparés, cela reste plus compliqué que de faire une copie des fichiers dans un aurte répertoire et de changer une constante.. dans le web.config) .
mettre tous les fichiers dans un seul répertoire facilite également le backup (pas grand chose, mais quand même).
pour gérer l'accès, il suffit (si je me souviens bien) de donner les droits au user asp_net (lecture/écriture) à ton fileshare/répertoire.
Pour le restart, en fait, dès que tu modifies la structure du folder de ton application (ou un sous folder, fichier, ...) il y a de fortes chances que l'application redémarre (perte de toutes les variables session et application + cache) car le folder applicatif est considéré comme une partie de l'application (donc restart, tout comme si tu mettais une nouvelle version de la dll).
yopyop
comme tu l'as dit, ta solution nécessite d'avoir le chemin complet du fichier dans la base. donc si un jour tu changes ton répertoire, cela risque de compliquer les choses (même si le chemin et le filename sont dans 2 champs séparés, cela reste plus compliqué que de faire une copie des fichiers dans un aurte répertoire et de changer une constante.. dans le web.config) .
mettre tous les fichiers dans un seul répertoire facilite également le backup (pas grand chose, mais quand même).
pour gérer l'accès, il suffit (si je me souviens bien) de donner les droits au user asp_net (lecture/écriture) à ton fileshare/répertoire.
Pour le restart, en fait, dès que tu modifies la structure du folder de ton application (ou un sous folder, fichier, ...) il y a de fortes chances que l'application redémarre (perte de toutes les variables session et application + cache) car le folder applicatif est considéré comme une partie de l'application (donc restart, tout comme si tu mettais une nouvelle version de la dll).
yopyop
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
mdemo
Messages postés
90
Date d'inscription
mardi 21 mars 2006
Statut
Membre
Dernière intervention
10 mai 2010
29 août 2006 à 23:53
29 août 2006 à 23:53
Merci yopyop pour tes conseils.
Last question: quel est ton avis sur les répertoires créés avec le UserId qui est un Guid ? Ca présente l'intérêt d'éviter les doublons éventuels, de protéger dans une certaine mesure, mais je me demande si compte tenu de la longueur et des caractères utilisés il n'y aurait pas une incompatibilité...
Last question: quel est ton avis sur les répertoires créés avec le UserId qui est un Guid ? Ca présente l'intérêt d'éviter les doublons éventuels, de protéger dans une certaine mesure, mais je me demande si compte tenu de la longueur et des caractères utilisés il n'y aurait pas une incompatibilité...
cs_Yopyop
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
30 août 2006 à 11:08
30 août 2006 à 11:08
re,
questions toutes bêtes :
tu vas utiliser SQL Server ?
pourquoi un GUID (c'est une string donc si tu l'utilises comme identitfiant cela risque de ralentir les requêtes notemment lors de jointures etc...) ?
pourquoi ne pas utiliser tout simplement l'id (identity) ?
GUID est surtout utilisé lorsque tu partages tes données sur plusieurs serveur de données (autrement il n'y pas grand intérêt à mon humble avis), de plus, rien ne garanti qu'il soit unique (faut vraiment pas avoir de chance).
Donc si le but est d'éviter les doublons, il faut utiliser l'identity et non le GUID.
Mais tout dépends de la base de données que tu vas utiliser...
Combien de users vas-tu gérer ?
yopyop
questions toutes bêtes :
tu vas utiliser SQL Server ?
pourquoi un GUID (c'est une string donc si tu l'utilises comme identitfiant cela risque de ralentir les requêtes notemment lors de jointures etc...) ?
pourquoi ne pas utiliser tout simplement l'id (identity) ?
GUID est surtout utilisé lorsque tu partages tes données sur plusieurs serveur de données (autrement il n'y pas grand intérêt à mon humble avis), de plus, rien ne garanti qu'il soit unique (faut vraiment pas avoir de chance).
Donc si le but est d'éviter les doublons, il faut utiliser l'identity et non le GUID.
Mais tout dépends de la base de données que tu vas utiliser...
Combien de users vas-tu gérer ?
yopyop
mdemo
Messages postés
90
Date d'inscription
mardi 21 mars 2006
Statut
Membre
Dernière intervention
10 mai 2010
30 août 2006 à 16:05
30 août 2006 à 16:05
En fait j'avais commencé par gérer mes membres avec un integer qui s'incrémentait (Est ce que c'est ce que tu appelles identity?).
Puis depuis une semaine j'ai mis en place les logins... avec les contrôles serveurs de VS2005. Ca m'a donc créé la base aspnet.mdf que j'ai mergée avec la mienne. (on parle bien de sql server 2005).
Chaque nouveau membre créé pas ces contrôles a un UserId qui est un Guid; Je pouvais donc soit faire une table de conversion avec mes IdMember (integer) et UserId (Guid), soit tout reprendre avec ce UserId afin d'avoir un seul identifiant.
J'ai choisi cette seconde solution car le site n'est pas encore lancé. Mais j'ai peut être fait un mauvais choix ?
Pour ce qui est du nombre de users, c'est un grand mystère! Je pense toutefois que nous parlons facilement de plusieurs milliers. Est-ce que le guid a une si grosse incidence sur les requêtes?
Merci
Puis depuis une semaine j'ai mis en place les logins... avec les contrôles serveurs de VS2005. Ca m'a donc créé la base aspnet.mdf que j'ai mergée avec la mienne. (on parle bien de sql server 2005).
Chaque nouveau membre créé pas ces contrôles a un UserId qui est un Guid; Je pouvais donc soit faire une table de conversion avec mes IdMember (integer) et UserId (Guid), soit tout reprendre avec ce UserId afin d'avoir un seul identifiant.
J'ai choisi cette seconde solution car le site n'est pas encore lancé. Mais j'ai peut être fait un mauvais choix ?
Pour ce qui est du nombre de users, c'est un grand mystère! Je pense toutefois que nous parlons facilement de plusieurs milliers. Est-ce que le guid a une si grosse incidence sur les requêtes?
Merci
cs_Yopyop
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
30 août 2006 à 16:50
30 août 2006 à 16:50
re,
comme indiqué plus haut, le GUID est une string.
Donc si tu fais des jointures sur des strings, cela sera fatalement plus lent (de beaucoup) que des jointures sur des nombres.
j'utilise vs2003 avec sql server 2000 et l'une des base de données sur laquelle je travaille a environs 300'000 users (oui c'est une grosse boîte).
L'utilisation des GUID est hors de question dans le contexte dans lequel je travaille (infime probabilité d'avoir 2 fois le même GUID).
comment se fait-il que tes contrôles génèrent des GUID ? tu ne peux pas les forcer à créer une id "simple".
par example (example basique), pour créer une table id,login,password
create table dbo.USERS(
ID numeric(10) identity,
LOGIN varchar(20) not null,
PASSWORD varchar(20) not null,
constraint USER_PK primary key (ID),
constraint USER_LOG_PASS_UK unique (LOGIN,PASSWORD)
)
go
ensuite, lors d'un insert
insert into users
(login,password) values ('monlogin','monpassword')
l'id est créée automatiquement.
ensuite pour récupérer la nouvelle id
select @@identity (ou @@scope_identity)
le tout dans une transaction :)
mes users ont automatiquement un nouvelle id, qui est unique à coup sûr.
perso, je n'utiliserai pas le GUID (jamais !;) comme identifiant interne à ma base de données.
Le seul cas ou j'utiliserai un GUID, c'est si, par example, je me retrouve avec 2 (ou N) bases de données différentes qui ont toutes la même table users.
Dans ce cas l'utilisation du GUID est une "bonne" solution (et encore!).
Il ne faut pas perdre de vue que le GUID n'est pas forcément unique !
C'est une chaîne de charactères générée "au hasard" qui assez longue pour que la probabilité d'avoir 2 fois la même est quasi nulle.
Mais cette probabilité existe toujours (ok, c'est la même probabilité que de gagner à l'euromillion, au lotto et au pmu et de se faire écraser par une météorite le même jour).
j'espère que cela t'aide...
yopyop
comme indiqué plus haut, le GUID est une string.
Donc si tu fais des jointures sur des strings, cela sera fatalement plus lent (de beaucoup) que des jointures sur des nombres.
j'utilise vs2003 avec sql server 2000 et l'une des base de données sur laquelle je travaille a environs 300'000 users (oui c'est une grosse boîte).
L'utilisation des GUID est hors de question dans le contexte dans lequel je travaille (infime probabilité d'avoir 2 fois le même GUID).
comment se fait-il que tes contrôles génèrent des GUID ? tu ne peux pas les forcer à créer une id "simple".
par example (example basique), pour créer une table id,login,password
create table dbo.USERS(
ID numeric(10) identity,
LOGIN varchar(20) not null,
PASSWORD varchar(20) not null,
constraint USER_PK primary key (ID),
constraint USER_LOG_PASS_UK unique (LOGIN,PASSWORD)
)
go
ensuite, lors d'un insert
insert into users
(login,password) values ('monlogin','monpassword')
l'id est créée automatiquement.
ensuite pour récupérer la nouvelle id
select @@identity (ou @@scope_identity)
le tout dans une transaction :)
mes users ont automatiquement un nouvelle id, qui est unique à coup sûr.
perso, je n'utiliserai pas le GUID (jamais !;) comme identifiant interne à ma base de données.
Le seul cas ou j'utiliserai un GUID, c'est si, par example, je me retrouve avec 2 (ou N) bases de données différentes qui ont toutes la même table users.
Dans ce cas l'utilisation du GUID est une "bonne" solution (et encore!).
Il ne faut pas perdre de vue que le GUID n'est pas forcément unique !
C'est une chaîne de charactères générée "au hasard" qui assez longue pour que la probabilité d'avoir 2 fois la même est quasi nulle.
Mais cette probabilité existe toujours (ok, c'est la même probabilité que de gagner à l'euromillion, au lotto et au pmu et de se faire écraser par une météorite le même jour).
j'espère que cela t'aide...
yopyop
mdemo
Messages postés
90
Date d'inscription
mardi 21 mars 2006
Statut
Membre
Dernière intervention
10 mai 2010
30 août 2006 à 18:03
30 août 2006 à 18:03
Seulement 300000 users !
Je plaisante.
Pire que ça le guid est un objet Guid en .Net, et un uniqueidentifier en Sql. Et bien sûr on doit sans cesse le convertir en string.
Je sais bien que j'ai dû prendre une mauvaise direction. Depuis le début j'ai fait ce que tu m'as décrit, mais j'ai bêtement changé d'avis afin d'avoir un Id unique avec le membership...
Je mets de côté l'argument probabilité (sauf si j'atteins le milliard de users!). Par contre je me pose des questions sur les perfs depuis le début, et je pense que tu as raison surtout que tu es confronté à ça (moi j'avais idmember = 1 !). Tu vas donc m'obliger à revoir mes tables, mes procédures, mes classes... que j'ai modifiées il y a moins d'une semaine dans l'autre sens !
Le hic est que je me suis laissé avoir par toute la nouvelle gestion des membres des 2.0 : c'est là que le guid est créé. Tout est géré avec de UserId créé avec le CreateUserWizard. Toutes les tables et procédures stockées ont ce guid.
Tu peux jeter un coup d'oeil à:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/asp2prvdr06.asp
<gras>http://aspnet.4guysfromrolla.com/articles/070506-1.aspx
Voyant qu'ils étaient repartis en utilisant ce guid, je me suis bêtement dit qu'il fallait finalement faire de même.
Tu avoueras qu'il est quand même dommage de gérer deux ids par user. Mais quand je vois le nombre de requêtes que je vais devoir faire sur mes fichiers, il est en effet bien plus judicieux de revenir à mon identity de départ.
Merci mille fois pour tous tes conseils très très précieux. Je me pose souvent des questions de ce type, et comme je manque de recul et d'expérience je me demande souvent si j'ai pris la bonne direction. Dès ce soir je retourne dans le droit chemin...
Je plaisante.
Pire que ça le guid est un objet Guid en .Net, et un uniqueidentifier en Sql. Et bien sûr on doit sans cesse le convertir en string.
Je sais bien que j'ai dû prendre une mauvaise direction. Depuis le début j'ai fait ce que tu m'as décrit, mais j'ai bêtement changé d'avis afin d'avoir un Id unique avec le membership...
Je mets de côté l'argument probabilité (sauf si j'atteins le milliard de users!). Par contre je me pose des questions sur les perfs depuis le début, et je pense que tu as raison surtout que tu es confronté à ça (moi j'avais idmember = 1 !). Tu vas donc m'obliger à revoir mes tables, mes procédures, mes classes... que j'ai modifiées il y a moins d'une semaine dans l'autre sens !
Le hic est que je me suis laissé avoir par toute la nouvelle gestion des membres des 2.0 : c'est là que le guid est créé. Tout est géré avec de UserId créé avec le CreateUserWizard. Toutes les tables et procédures stockées ont ce guid.
Tu peux jeter un coup d'oeil à:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/asp2prvdr06.asp
<gras>http://aspnet.4guysfromrolla.com/articles/070506-1.aspx
Voyant qu'ils étaient repartis en utilisant ce guid, je me suis bêtement dit qu'il fallait finalement faire de même.
Tu avoueras qu'il est quand même dommage de gérer deux ids par user. Mais quand je vois le nombre de requêtes que je vais devoir faire sur mes fichiers, il est en effet bien plus judicieux de revenir à mon identity de départ.
Merci mille fois pour tous tes conseils très très précieux. Je me pose souvent des questions de ce type, et comme je manque de recul et d'expérience je me demande souvent si j'ai pris la bonne direction. Dès ce soir je retourne dans le droit chemin...
mdemo
Messages postés
90
Date d'inscription
mardi 21 mars 2006
Statut
Membre
Dernière intervention
10 mai 2010
30 août 2006 à 20:28
30 août 2006 à 20:28
Thanks, you are my new Guid !
Tu as entièrement raison, et c'est pourquoi j'espérais que d'autres personnes se joindraient au débat... Il n'est pas facile d'obtenir de vrais échanges sur les forums, et c'est pourquoi j'apprécie le temps que tu me consacres.
J'ai en effet constaté que les tutoriaux donnent toujours une impression de facilité, ce qui est logique, et que derrière ça ne marche pas pareil, loin de là. Un bon exemple est la localisation et les masterpages, qui marchent super bien en théorie.. Le côté positif est que ça permet d'apprendre plein de trucs. Et je lis beaucoup (amazon m'adore).
J'ai découvert, mais trop tard, les infos suivantes (dans livre sql server 2005) qui vont t'intéresser et confirmer tes propos:
The uniqueidentifier data type is an advanced data type that the typical reader of this book (il parle de moi) should no use. It is very resource intensive because of its length. The introduction of the NEWSEQUENTIALID function with SQL Server 2005 makes uniqueidentifiers more comparable than in previous SQL versions to IDENTITY values as primary keys and index values generally. Nevertheless, there is stil a substantial performance penalty associated with uniqueidentifier values relative to data types used with an IDENTITY property.
La question est maintenant posée: pourquoi MS utilise un uniqueidentifier pour gérer les membres ? D'un autre côté à partir de combien de membres les questions de performances sont-elles posées...
J'ai le bouquin idéal pour refaire moi-même la gestion des logins, memberships, sécurité sous 2.0... 600 pages rien que sur ça en anglais. J'ai commencé à l'éplucher mais je n'ai clairement pas le niveau, et encore moins le temps, pour faire quelque chose de correct et surtout mieux que MS sinon ça ne sert à rien. J'ai donc pris le parti d'utiliser leurs outils qui offrent de sacrés avantages clés en mains (login, loginview, status, le nom de son chien, de sa maitresse, l'envoi auto d'un nouveau pw, limitation du nombre de tentatives, gestion membership, roles... Bref comme je n'ai pour une fois pas de besoins particuliers, contrairement au reste de mon site, ça devrait faire l'affaire, sauf ce sacré userid, mais ce n'est finalement pas bien grave.
Pour ce qui est de l'accés aux données (relatif ou absolu), je n'ai toujours pas fait de choix définitif...On va continuer à étudier ça avant de finaliser!
Encore merci et à bientôt !
Tu as entièrement raison, et c'est pourquoi j'espérais que d'autres personnes se joindraient au débat... Il n'est pas facile d'obtenir de vrais échanges sur les forums, et c'est pourquoi j'apprécie le temps que tu me consacres.
J'ai en effet constaté que les tutoriaux donnent toujours une impression de facilité, ce qui est logique, et que derrière ça ne marche pas pareil, loin de là. Un bon exemple est la localisation et les masterpages, qui marchent super bien en théorie.. Le côté positif est que ça permet d'apprendre plein de trucs. Et je lis beaucoup (amazon m'adore).
J'ai découvert, mais trop tard, les infos suivantes (dans livre sql server 2005) qui vont t'intéresser et confirmer tes propos:
The uniqueidentifier data type is an advanced data type that the typical reader of this book (il parle de moi) should no use. It is very resource intensive because of its length. The introduction of the NEWSEQUENTIALID function with SQL Server 2005 makes uniqueidentifiers more comparable than in previous SQL versions to IDENTITY values as primary keys and index values generally. Nevertheless, there is stil a substantial performance penalty associated with uniqueidentifier values relative to data types used with an IDENTITY property.
La question est maintenant posée: pourquoi MS utilise un uniqueidentifier pour gérer les membres ? D'un autre côté à partir de combien de membres les questions de performances sont-elles posées...
J'ai le bouquin idéal pour refaire moi-même la gestion des logins, memberships, sécurité sous 2.0... 600 pages rien que sur ça en anglais. J'ai commencé à l'éplucher mais je n'ai clairement pas le niveau, et encore moins le temps, pour faire quelque chose de correct et surtout mieux que MS sinon ça ne sert à rien. J'ai donc pris le parti d'utiliser leurs outils qui offrent de sacrés avantages clés en mains (login, loginview, status, le nom de son chien, de sa maitresse, l'envoi auto d'un nouveau pw, limitation du nombre de tentatives, gestion membership, roles... Bref comme je n'ai pour une fois pas de besoins particuliers, contrairement au reste de mon site, ça devrait faire l'affaire, sauf ce sacré userid, mais ce n'est finalement pas bien grave.
Pour ce qui est de l'accés aux données (relatif ou absolu), je n'ai toujours pas fait de choix définitif...On va continuer à étudier ça avant de finaliser!
Encore merci et à bientôt !
jesusonline
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Membre
Dernière intervention
13 octobre 2010
29
5 sept. 2006 à 00:35
5 sept. 2006 à 00:35
Christian s'interesse à la question du Indentity Vs Guid : http://blogs.developpeur.org/christian/archive/2006/08/30/GUID_versus_Identity_Partie_I.aspx
Je ne suis pas un expert SQL (loin de là :p) mais il y a du pour et tu contre :-) Pour ce qui est des Membership/Profiles d'ASP.net 2 c'est trés bien pour les tous petits sites de débutant mais si on veut faire des vrais trucs il faut créer son propre Membership Provider ou carrement utiliser son propre systeme de login (mais je conseille quand meme la création d'un membership qui permet l'utilisation des controles de login)
En ce qui concerne ta condition initiale, je suis contre l'idée de mettre des fichiers "données" sur le disque dur ! d'une part c'est la galère de configurer les droits windows si le compte aspnet de la machine A doit écrire sur le repertoire partagé de la machine B, et puis il vaut mieux limiter les accés en écriture du compte aspnet :-) D'autre part je pense que tout ce qui est données DOIT être dans la base de données, pour les backup & co c'est déjà beaucoup plus simple et il est pas impossible que SQL 2005 soit plus rapide que le FileSystem de windows (ce serait à vérifier bien sur)
Pour moi c'est personalisation du Membership provider et enregistrement de tous les fichiers dans SQL !
PS : je vais envoyé un mail à Christian pour le faire venir ici ;-)
<hr />Cyril - MVS - MCP
Je ne suis pas un expert SQL (loin de là :p) mais il y a du pour et tu contre :-) Pour ce qui est des Membership/Profiles d'ASP.net 2 c'est trés bien pour les tous petits sites de débutant mais si on veut faire des vrais trucs il faut créer son propre Membership Provider ou carrement utiliser son propre systeme de login (mais je conseille quand meme la création d'un membership qui permet l'utilisation des controles de login)
En ce qui concerne ta condition initiale, je suis contre l'idée de mettre des fichiers "données" sur le disque dur ! d'une part c'est la galère de configurer les droits windows si le compte aspnet de la machine A doit écrire sur le repertoire partagé de la machine B, et puis il vaut mieux limiter les accés en écriture du compte aspnet :-) D'autre part je pense que tout ce qui est données DOIT être dans la base de données, pour les backup & co c'est déjà beaucoup plus simple et il est pas impossible que SQL 2005 soit plus rapide que le FileSystem de windows (ce serait à vérifier bien sur)
Pour moi c'est personalisation du Membership provider et enregistrement de tous les fichiers dans SQL !
PS : je vais envoyé un mail à Christian pour le faire venir ici ;-)
<hr />Cyril - MVS - MCP
mdemo
Messages postés
90
Date d'inscription
mardi 21 mars 2006
Statut
Membre
Dernière intervention
10 mai 2010
7 sept. 2006 à 13:34
7 sept. 2006 à 13:34
Merci Cyril pour ton point de vue. Ca ne m'arrange pas que tu sois contre l'idée de mettre des données sur le disque :-)
C'est en effet un autre vaste débat que tu ouvres... J'ai longuement étudié ça sans jamais trop savoir quelle décision prendre. Mais je suis à un stade où passer tout en sql est encore envisageable. Il est clair que les arguments sauvergarde et droits sont imparables. Mais penses-tu vraiment que tout ce qui concerne par exemple des vidéos, des photos, des documents... doivent être directement dans la base en binaire ? Dans l'hypothèse par ex de nombreuses vidéos uploadées, ou d'autres fichiers très gros, la base va devenir rapidement énorme même avec peu d'utilisateurs, et pourquoi pas le disque trop petit. Que se passe-t-il alors ? Comment Sql server gère-t-il ça ?
Ne vaut-il pas mieux dans ce cas là avoir une base plus light et des solutions de sauvegardes sur d'autres disques, quitte en effet à être pénalisé peut être en temps d'accés ?
Je souhaite juste comprendre les tenants et aboutissants, car techniquement je ne maitrise pas toutes ces notions d'accès en écriture, de partage... ce qui ne facilite pas une bonne prise de décision !
Il faut bien voir que je suis bien loin de tous ces problèmes actuellement, et que peut être ils ne se poseront jamais (mais ce n'est pas le but!). Mais j'ai envie de comprendre, et surtout de bien structurer les choses dès le départ.
Merci.
C'est en effet un autre vaste débat que tu ouvres... J'ai longuement étudié ça sans jamais trop savoir quelle décision prendre. Mais je suis à un stade où passer tout en sql est encore envisageable. Il est clair que les arguments sauvergarde et droits sont imparables. Mais penses-tu vraiment que tout ce qui concerne par exemple des vidéos, des photos, des documents... doivent être directement dans la base en binaire ? Dans l'hypothèse par ex de nombreuses vidéos uploadées, ou d'autres fichiers très gros, la base va devenir rapidement énorme même avec peu d'utilisateurs, et pourquoi pas le disque trop petit. Que se passe-t-il alors ? Comment Sql server gère-t-il ça ?
Ne vaut-il pas mieux dans ce cas là avoir une base plus light et des solutions de sauvegardes sur d'autres disques, quitte en effet à être pénalisé peut être en temps d'accés ?
Je souhaite juste comprendre les tenants et aboutissants, car techniquement je ne maitrise pas toutes ces notions d'accès en écriture, de partage... ce qui ne facilite pas une bonne prise de décision !
Il faut bien voir que je suis bien loin de tous ces problèmes actuellement, et que peut être ils ne se poseront jamais (mais ce n'est pas le but!). Mais j'ai envie de comprendre, et surtout de bien structurer les choses dès le départ.
Merci.
jesusonline
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Membre
Dernière intervention
13 octobre 2010
29
7 sept. 2006 à 13:40
7 sept. 2006 à 13:40
Bonjour,
quelle la différence entre ecriture directement sur le disque et dans sql server ? la facilité de recuperer ces données. En fait il faut voir le file system de windows comme étant un concurrent de sql server 2005 (c'est d'ailleurs la raison de la naissance de winFS pour ne pas faire 2 fois la meme chose, mais la est encore un autre débat)
Entre Sql 2005 et NTFS, as ton avis quelle est le plus simple, performant ? Aprés si le disque est trop petit je ne vois pas la différence entre sql2005 et ntfs, dans les 2 cas il faudras que tu agrandisse ton disque physique (sauf si tu aimes la galère et que tu enregistre tes données à 2 endroits)
Bref moi j'hésiterais pas une seconde, et pourtant j'aime pas du tout SQL (JavaScript est mon ami ;))
<hr />Cyril - MVS - MCP
quelle la différence entre ecriture directement sur le disque et dans sql server ? la facilité de recuperer ces données. En fait il faut voir le file system de windows comme étant un concurrent de sql server 2005 (c'est d'ailleurs la raison de la naissance de winFS pour ne pas faire 2 fois la meme chose, mais la est encore un autre débat)
Entre Sql 2005 et NTFS, as ton avis quelle est le plus simple, performant ? Aprés si le disque est trop petit je ne vois pas la différence entre sql2005 et ntfs, dans les 2 cas il faudras que tu agrandisse ton disque physique (sauf si tu aimes la galère et que tu enregistre tes données à 2 endroits)
Bref moi j'hésiterais pas une seconde, et pourtant j'aime pas du tout SQL (JavaScript est mon ami ;))
<hr />Cyril - MVS - MCP
cs_skweeky
Messages postés
259
Date d'inscription
mercredi 3 mai 2006
Statut
Membre
Dernière intervention
11 janvier 2010
8
7 sept. 2006 à 15:40
7 sept. 2006 à 15:40
Bon je vais me meller au débat...
En ce qui concerne les GUID il faux connaitre ses avantages :
- Unicité quelque soit la machine
- Nature aléatoire donc impossible à deviner
- Depuis 2005 NEWSEQUENTIALID() qui permet de générer des GUID séquenciel, donc moins de risques de fragmentation (voir en dessous), mais possibilité de deviner la valeur suivante...
et ses inconvénients :
- Taille x4 par rapport à un int (donc 4x plus lent que le int dans certaines opérations (à relativiser tout de même))
- Risque de fragmentation des données (ralentissement des lectures et écritures en bases de données)
Il faut peser le pour et le contre, personnellement je ne l'utilise que peu, je suis défenseur de "si on a pas le choix alors...", typiquement
- Un ordinateur déconnecté a besoin d'un Id qui sera unique lors d'une resynchronisation
- Je veux une valeur impossible à déterminer et unique
Pour le débat entre système de fichier et base SQL Server, il faut s'interesser se poser la question de la manière dont sont stocker les fichiers.
Sous SQL Server un "blob" ou binary large object est stockée comme toute données dans des pages de 8ko (dont uniquement 8060 octets sont utilisables), pour gérer celà SQL contruit un arbre permettant de savoir où se trouve les pages relatives à ce blob... Résultat le blob occupe plus d'espace stockée dans SQL Server que directement sur le disque donc ici c'est clairement plus efficace se le stocker en fichier.
Avantage par contre à SQL Server si on utilise le moteur d'indexation (Full Text Search (FTS)) qui va associer à la clef primaire de la table des mots clefs relatifs au contenu du champ blob.... Grace aux iFilter il peux même gérer des documents PDF, etc...
Cas typique de ce genre d'usage, Sharepoint / WSS qui l'utilise et stocke les fichiers en base.
Au niveau de la sécurité il y a aussi une différence dans un cas sécurité intégrée à Windows (NTFS) dans l'autres celle de SQL Server (SQL Server), laquelle choisir...
En terme de performance avantage clair à NTFS en tout cas !
Christian Robert - Winwise
http://blogs.developpeur.org/christian/
MCT - Database Development / Database Administration
En ce qui concerne les GUID il faux connaitre ses avantages :
- Unicité quelque soit la machine
- Nature aléatoire donc impossible à deviner
- Depuis 2005 NEWSEQUENTIALID() qui permet de générer des GUID séquenciel, donc moins de risques de fragmentation (voir en dessous), mais possibilité de deviner la valeur suivante...
et ses inconvénients :
- Taille x4 par rapport à un int (donc 4x plus lent que le int dans certaines opérations (à relativiser tout de même))
- Risque de fragmentation des données (ralentissement des lectures et écritures en bases de données)
Il faut peser le pour et le contre, personnellement je ne l'utilise que peu, je suis défenseur de "si on a pas le choix alors...", typiquement
- Un ordinateur déconnecté a besoin d'un Id qui sera unique lors d'une resynchronisation
- Je veux une valeur impossible à déterminer et unique
Pour le débat entre système de fichier et base SQL Server, il faut s'interesser se poser la question de la manière dont sont stocker les fichiers.
Sous SQL Server un "blob" ou binary large object est stockée comme toute données dans des pages de 8ko (dont uniquement 8060 octets sont utilisables), pour gérer celà SQL contruit un arbre permettant de savoir où se trouve les pages relatives à ce blob... Résultat le blob occupe plus d'espace stockée dans SQL Server que directement sur le disque donc ici c'est clairement plus efficace se le stocker en fichier.
Avantage par contre à SQL Server si on utilise le moteur d'indexation (Full Text Search (FTS)) qui va associer à la clef primaire de la table des mots clefs relatifs au contenu du champ blob.... Grace aux iFilter il peux même gérer des documents PDF, etc...
Cas typique de ce genre d'usage, Sharepoint / WSS qui l'utilise et stocke les fichiers en base.
Au niveau de la sécurité il y a aussi une différence dans un cas sécurité intégrée à Windows (NTFS) dans l'autres celle de SQL Server (SQL Server), laquelle choisir...
En terme de performance avantage clair à NTFS en tout cas !
Christian Robert - Winwise
http://blogs.developpeur.org/christian/
MCT - Database Development / Database Administration