Conseils sur accès aux données

Bonjour,
Je travaille sur un site qui risque d'héberger pas mal de données uploadées par les membres. Ces membressont repérés par le UserId généré par le login (un Guid). Celà m'amène à poser 2 questions pour m'aider dans mon développement:
- je souhaite générer un répertoire par membre, ce répertoire ayant comme nom le Guid. Est-ce que celà pose un problème particulier, ou y-a-t-il une meilleure solution ?
- les divers contrôles accèdent aux données par des chemins relatifs ( avec "~/" pour les contrôles serveurs et "../" pour les contrôles html). Donc seul le nom du fichier est sauvegardé dans la base sql server. Que se passe-t-il si je suis amené plus tard à mettre des données sur un second disque, voire sur un autre serveur ? La solution sera-t-elle alors de passer par un chemin absolu, et avec toutes ses contraintes ? Avez-vous une meilleure solution ? Et surtout comment faire pour structurer ça dès maintenant pour éviter d'avoir des problèmes si un jour ça se produit ? Est-ce que ça se joue à mon niveau (code, sql) ou bien puis je expliquer plus tard au serveur de rechercher les chemins relatifs à différents endroits ?

Merci d'avance pour vos conseils.
 

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

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



 



 

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

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é...

 

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

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

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

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 à:

[ Lien ]

Table 1-3. The aspnet_Users table

Column Name	Column Type	Description
ApplicationId	uniqueidentifier	Application ID
UserId	uniqueidentifier	User ID
UserName	nvarchar(256)	User name
LoweredUserName	nvarchar(256)	User name (lowercase)
MobileAlias	nvarchar(16)	User's mobile alias (currently not used)
IsAnonymous	bit	1=Anonymous user, 0=Not an anonymous user
LastActivityDate	datetime	Date and time of last activity by this user

 
Même l'applicationid qui est un guid. Mais là c'est plus compréhensible car ça correspond à ce que tu as expliqué.

Pour ajouter d'autres infos (addresse...), pas moyen bien sûr dans ces tables, et pas touche aux stores procedures. Il y a la solution Profile expliquée partout, mais pas pratique pour accéder aux données, ou l'ajoût d'une autre table bien sûr.
ex: [ Lien ] 
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...