Je crée une API RESTful. J'ai du mal à décider de la meilleure façon de concevoir mes tables de base de données autour de mes ressources.
Au départ, je pensais qu'une table par ressource serait une bonne façon de procéder, mais je crains maintenant que cela ne se traduise par des tables exponentiellement plus grandes au fur et à mesure de la chaîne de ressources.
Par exemple, imaginez que j'ai trois ressources: les utilisateurs, les clients et les ventes. Les utilisateurs sont abonnés à mon API, les clients sont les utilisateurs des clients et les ventes sont des achats effectués par chaque client sur le compte des utilisateurs.
Une ressource de vente est accessible comme suit
GET /users/{userID}/clients/{clientID}/sales/{salesID}Donc, s'il y a 10 utilisateurs, chacun avec 10 clients, et pour chaque client il y a 10 ventes, la taille de la table augmente au fur et à mesure de la chaîne de ressources.
Je suis assez confiant que SQL peut gérer de grandes tables, mais je ne sais pas comment la lecture et l'écriture ralentiront les choses. L'exemple ci-dessus ne l'illustre peut-être pas, mais mon API aura progressivement plus d'écritures et de lectures au fur et à mesure de la chaîne de ressources. J'ai donc le scénario où les plus grandes tables de ma base de données seront lues et écrites plus souvent que les petites tables.
Il sera également nécessaire de joindre des tables avant d'exécuter des requêtes. La raison en est que j'autorise chaque utilisateur à avoir un client du même nom. Pour éviter d'obtenir des données client incorrectes, la table des utilisateurs et les tables des clients sont jointes par {userID}. C'est également le cas pour les ventes. Rejoindre de grandes tables et exécuter des lectures et des écritures ralentira-t-il encore les choses?
Les bases de données relationnelles (d'où SQL) sont très efficaces pour localiser une (ou quelques) lignes d'une immense table. C'est à cela que servent les index. Ils sont également assez géniaux pour gérer les jointures. Vous n'avez pas vraiment de question . Entre les lignes, vous demandez essentiellement comment faire une conception de base de données multi-locataire. Je vous suggère de lire l' architecture de données multi-locataire avant de poser d'autres questions. Choisissez l'un des modèles (base de données distincte, schémas séparés de base de données partagée, schéma partagé de base de données partagée), puis nous allons discuter des spécificités. À l'heure actuelle, vous n'envisagez que le dernier modèle, mais ne considérez pas les avantages et les inconvénients. Lisez.
En remarque: vous n'avez pas besoin
user/{userID}de l'URI. Vous connaissez le locataire (ID utilisateur) à partir des informations d'authentification.la source
user_idtant que clé à chaque table et ajouterleft.user_id = right.user_idaux jointures pertinentes (généralement, toutes). Certains ORM prennent en charge la suppression de l'accès. Et ne vous y trompez pas, vos utilisateurs sont locataires, car vous ne voulez pas que l'utilisateur 'foo' voie / modifie les ventes de l'utilisateur 'bar'.Juste pour ajouter à ce qui a déjà été dit ici - vous voudrez peut-être créer une interface entre l'API réelle et votre couche de base de données. Cela facilite l'ajout de cache et de tableaux récapitulatifs sur toute la ligne ...
la source