question de modélisation des données

Mes clients utilisent une des opérations suivantes lors de leur inscription à ma demande:question de modélisation des données

Foo API (nécessite un "auth_key", "mot de passe", "email ")
API Acme (nécessite un" secure_code " "nom d'utilisateur"," mot de passe ")
Bar API (nécessite un" xyz_code "" pass_key «)

(faux noms, et 15 plus omis pour simplifier)

I Je préférerais ne pas avoir 10-15 tables dans ma base de données juste pour les différentes options d'intégration d'API que je propose (en particulier quand elles sont toutes pour la même chose et qu'elles choisissent simplement 1 dans la liste complète).

Ma solution était la suivante:

Faire une table api_configuration avec une colonne appelée api_name qui contient un code pour une API spécifique (par exemple "foo_api")

Faire une table appelée credentials_attribute avec une clé étrangère retour à api_configuration , une colonne appelée name et une colonne appelée value.

Ensuite, je construis une interface utilisateur pour choisir une API. S'ils choisissent l'API Acme, ils demanderont un "code_sécurisé", un "nom d'utilisateur" et un "mot de passe", et créeront une ligne au credentials_attribute pour chacune des paires nom/valeur.

Sur mon modèle ORM pour api_configuration Je peux faire une méthode pour rechercher des valeurs credentials_attribute basées sur le courant api_name.

Cette solution vous semble-t-elle correcte ou existe-t-il un autre moyen de le faire si vous deviez modéliser une solution à ce problème? S'il vous plaît expliquer votre raisonnement ainsi (ie, mieux pour la performance, etc)

Source

2010-10-07 orokusaki

ça sonne bien, mais ne pourriez-vous pas créer une seule table? Nom d'utilisateur/email est la même chose (bien, vous pourriez le représenter de cette façon)? – RPM1984

@ RPM1984 - Je pourrais. Je voulais juste des opinions sur d'autres façons (comme celle que vous avez mentionnée). Je penche en partie vers une version non-plate, ce qui me permet plus tard d'utiliser plus d'une API, mais je l'ai laissé de côté parce que je ne voulais pas biaiser les réponses des gens en fonction de quelque chose qui n'est pas problème pour le moment. – orokusaki

La discussion de stackoverflow ci-dessous parle des avantages et des inconvénients des différentes approches ORM. Même si vous ne posez pas de question spécifique sur ORM, beaucoup de commentaires seront toujours applicables, car ils comparent les approches à table unique et les approches à tables multiples. http://stackoverflow.com/questions/3413459/designing-sql-database-to-represent-oo-class-hierarchy/3427434#3427434 – mikemanne

Si je comprends bien le cas, cela ressemble à un autre cas du modèle de conception de gen-spec. Recherchez la "modélisation relationnelle de spécialisation de généralisation".

Les didacticiels sur la modélisation d'objets couvrent généralement gen-spec, mais souvent les didacticiels sur la modélisation relationnelle ne le font pas. Mais c'est bien compris, et il y a d'excellents articles sur le web.

Source

2010-10-07 10:19:30

Si je vous comprends bien, toutes ces propriétés dans les différentes API sont conceptuellement tuples de la même chose, sous des noms différents, non? Votre description est du point de vue de DB - Je décrirai ce que je ferais sur le côté de domaine (qui peut être directement mappable à votre schéma).

Je créerais une classe unique, par ex. UserLogin, avec les 3 propriétés mentionnées ci-dessus (par exemple authenticationCode, userId, password), et un mappage des noms/codes d'API aux noms de propriété GUI. Lorsque l'utilisateur sélectionne l'API préférée, je peux afficher les champs avec les noms appropriés sur l'interface graphique, et remplir les valeurs aux propriétés correspondantes de UserLogin. Si nécessaire, UserLogin peut également stocker l'API de connexion préférée pour cet utilisateur. De cette façon, UserLogin est mappé à une seule table du côté DB. Je peux utiliser une autre table pour configurer les noms de propriété pour chaque API connue.

Source

2010-10-07 08:32:14

éter - non à la première question, j'ai édité ma question pour être plus explicite sur le la nature variable des paramètres d'authentification de chaque API. Certains ont 2, 3, et un a même 4. – orokusaki

@orokusaki, existe-t-il un plus petit dénominateur commun pour les attributs d'API (par exemple ID utilisateur et mot de passe)? Les champs supplémentaires peuvent-ils être facilement regroupés/mappés à quelques attributs communs? Si c'est le cas, j'essaierais toujours d'utiliser une seule classe contenant des champs obligatoires et des champs optionnels. Sinon, cette approche peut devenir gênante et irréalisable. –

éter - Je suis simplement curieux de savoir quel est le raisonnement derrière. Je peux penser à quelques raisons, mais je veux entendre le vôtre. – orokusaki

Je préférerais probablement le faire avec une seule table se

Avoir une seule UserAuthentication table avec des colonnes comme IdentificationKey, AuthenticationCriteria1, AuthenticationCriteria2 et ainsi de suite ...

Nombre de colonnes AuthenticationCriteriaX = nombre maximum de critères que les API aura. Je suppose que ce sera quelque chose de raisonnable comme peut-être 5 tout au plus, mais tout ce qui est jusqu'à 15-20 est en fait encore une jolie petite table.

UserAuthentication table a également une colonne api_key qui est une clé étrangère d'une table MASTER_API qui est la liste de tous

API pris en charge

En ce qui concerne la partie de l'interface utilisateur du problème, à savoir ce que l'étiquette pour montrer à l'utilisateur pour tout champ de la table UserAuthentication, je pense que c'est juste une question d'interface utilisateur et en tant que tel, vous devriez juste avoir la cartographie spécifique à chaque API quelque part dans votre couche d'interface utilisateur. La colonne api_key peut être utilisée pour la traduction si nécessaire. La base de données n'a pas nécessairement besoin de connaître ces détails, IMO.

Source

2010-10-07 08:40:35 InSane

Pourquoi recommandez-vous ce design aplati sur un autre? J'essaie de comprendre les différentes justifications que les administrateurs de bases de données et les architectes logiciels utilisent lorsqu'ils décident de ces choses. – orokusaki

Je suis d'accord avec @InSane - je préfère avoir une table. Avoir 15 tables avec le même résultat final est stupide. Est-ce plus flexible? Oui. Mais parfois, vous devez peser la flexibilité avec la sur-ingénierie. Vous pouvez toujours stocker les "choses principales" (ces trois champs) dans une seule table pour toutes les API, puis avoir un FK dans une table "type de méta-données", qui peut avoir des choses supplémentaires. – RPM1984

@orokusaki - mon raisonnement pour préférer une table unique est parce que logiquement - pour moi au moins - ce que vous avez, ce sont les données utilisées pour faire la même chose. - donc avoir des tables séparées pour cela ou même avoir une table horizontale est juste compliquer inutilement.Ce type de conception me permet d'obtenir un seul enregistrement pour un utilisateur et de me donner tous ces critères d'authentification en une fois. Même dans une perspective de croissance, si vous faites d'IdentificationKey + api_key une clé combinée, vous aborderez même facilement votre futur problème de prise en charge de plusieurs API pour le même utilisateur. – InSane

question de modélisation des données

Répondre

Questions connexes