MS SQL Server
  1. MS SQL Server
  3. Besoin d'aide pour concevoir un schéma de database pour une application SaaS
Intereting Posts
Sélectionnez distinct de lignes et affichez le nombre de chaque valeur Limitation des loggings dans une sélection random SQLtransactions dans TransactionScope Bogue étrange lors de l'insertion de DateTime sur le server sql 2008 SQL: ne pas afficher les duplicates SQL – Compter les résultats de 2 colonnes Aide de design de database SQL nécessaire SQL – Création d'une table de faits historiques à partir des dernières données de capture instantanée Comment passer le paramètre nvarchar de procédure stockée SQL avec hébreu? Modifiez les minuscules en majuscules (titre) à l'aide de la requête sql Calculer le nombre d'années entre les dates en Sql représentant des données booleannes dans le server sql Compter les loggings pour chaque mois de l'année Impossible de déployer le package: authentification SQL Server SQL2014 Convertir une sortie de colonne sélectionnée en list séparée par un point-virgule pour sp_send_dbmail

Besoin d'aide pour concevoir un schéma de database pour une application SaaS

Je suis développeur et je n'ai jamais travaillé sur DB avant (design d'une DB). Je suis en train de concevoir une database pour un système de gestion des employés qui est une application Node.js + Express utilisant MySQL comme database.

J'ai déjà les tables requirejses, les colonnes sortingées, mais il y a encore peu d'inconnues que j'ai à traiter. C'est mon plan jusqu'à présent et j'ai besoin de votre consortingbution à ce sujet.

  1. Les users finaux utilisant cette application seront de petites entresockets de taille moyenne. Les entresockets ne partageront pas les tables dans la database. Donc, s'il y a une table nommée EmployeeCases, je prévois de créer une nouvelle table EmployeeCases pour chaque entreprise existante ou une nouvelle qui s'inscrit pour cette application. Je prévois de nommer la table comme EmployeeCases_989809890, où "989809890" sera l'ID de la société (ou l'ID du client). Donc, si nous avons 3 ou 4 entresockets qui se sont inscrites, alors toutes les tables (du less celles utilisées par une entreprise) seront recréées et nommées TableName_CompanyId. Mes questions, est-ce un bon moyen d'y aller? Y a-t-il un meilleur moyen?

  2. Toutes datatables de l'employé sont détenues par la table des employés, y compris leur identifiant et mot de passe. Maintenant, chaque table d'employé dans DB sera nommée Employee_CompanyId (selon mon plan ci-dessus). Ma question est la suivante: lorsqu'un employé se connecte, comment saurai-je quelle table d'employés requestr? Ou devrais-je supprimer le login de la table Employee et créer une table Users universelle où tous les employés seront stockés? La table Users aura aussi l'CompanyId comme une de ses colonnes et je lirai le CompanyId à partir de là qui sera utilisé pour interroger d'autres tables.

Toute reference, site internet ou blogs sur ce type de design seront appréciés.

Merci.

Je ne recommand pas cette approche, je pense que vous devriez soit:

A) Mettre toutes les informations dans les mêmes tables et avoir une colonne compagnyId pour les sortinger

OU

B) Avoir des bases de données séparées pour chaque entreprise et utiliser la database appropriée en utilisant le code.

La chose est, avec votre approche, vous aurez du mal à maintenir votre application si vous avez plusieurs copys de la même table avec des noms différents. Si vous décidez d'append une colonne à l'une des tables par exemple, vous devrez écrire autant de scripts SQL que d'instances de tables. Vous aurez également un mauvais moment avec l'set de votre identifiant unique.

Voici quelques avantages / inconvénients de chaque design:

A) Mettre toutes les informations dans les mêmes tables et avoir une colonne compagnyId pour les sortinger

Avantages:

  • Le plus simple
  • Autoriser l'utilisation de keys / contraintes étrangères
  • Idéal pour l'extraction de données croisées / client

Désavantages:

  • Non portable (un client ne peut pas simplement partir avec ses données)
  • Peut être perçu comme less sûr (je suppose que vous pouvez faire l'affaire dans les deux sens)
  • Plus susceptible d'avoir d'énormes tables
  • Ne se balance pas très bien

B) Avoir des bases de données séparées pour chaque entreprise et utiliser la database appropriée en utilisant le code.

Avantages:

  • Portable
  • Peut être perçu comme plus sûr

Désavantages:

  • Besoin de plus de discipline pour suivre toutes les bases de données
  • Nécessite une bonne séparation de ce qui fait partie de votre HUB (Votre application qui identifie quel client accède à quelle database) et de ce qui fait partie de la database de votre client.
  • Vous avez besoin d'une page de connection par entreprise (ou requestz à vos clients de spécifier l'entreprise dans un champ)

Un exemple d'application qui utilise ce "login en deux étapes" est Slack , lorsque vous vous connectez vous entrez d'abord dans votre domaine d'équipe ALORS vos informations d'identification d'user.

Je pense que Google Apps for Work est la même approche. En outre, je pense que la plupart des CRM que j'ai travaillé avec une database séparée pour leurs clients.

Enfin, je voudrais vous diriger vers cette autre question sur stackoverflow qui renvoie à un exemple intéressant.

Vous ne devez pas split vos tables simplement parce que les entresockets ne partageront pas leurs informations. Au lieu de cela, vous devez avoir une colonne companyId dans chaque table et accéder aux données pertinentes pour chaque requête. Cela devrait être mis en œuvre dans votre backend