Conception de base de données pour la première fois: suis-je trop ingénieur? [fermé]

246

Contexte

Je suis un étudiant CS de première année et je travaille à temps partiel pour la petite entreprise de mon père. Je n'ai aucune expérience dans le développement d'applications dans le monde réel. J'ai écrit des scripts en Python, des cours en C, mais rien de tel.

Mon père a une petite entreprise de formation et actuellement toutes les classes sont planifiées, enregistrées et suivies via une application Web externe. Il existe une fonction d'exportation / "rapports" mais elle est très générique et nous avons besoin de rapports spécifiques. Nous n'avons pas accès à la base de données réelle pour exécuter les requêtes. On m'a demandé de mettre en place un système de reporting personnalisé.

Mon idée est de créer les exportations CSV génériques et de les importer (probablement avec Python) dans une base de données MySQL hébergée au bureau tous les soirs, d'où je peux exécuter les requêtes spécifiques qui sont nécessaires. Je n'ai pas d'expérience dans les bases de données mais je comprends les bases. J'ai lu un peu sur la création de bases de données et les formulaires normaux.

Nous pouvons commencer à avoir des clients internationaux bientôt, donc je veux que la base de données n'explose pas si / quand cela se produit. Nous avons également actuellement quelques grandes sociétés en tant que clients, avec différentes divisions (par exemple, société mère ACME, division soins de santé ACME, division soins corporels ACME)

Le schéma que j'ai trouvé est le suivant:

  1. Du point de vue du client:
    • Les clients sont la table principale
    • Les clients sont liés au département pour lequel ils travaillent
      • Les départements peuvent être dispersés à travers un pays: RH à Londres, Marketing à Swansea, etc.
      • Les départements sont liés à la division d'une entreprise
    • Les divisions sont liées à la société mère
  2. Du point de vue des classes:
    • Les sessions sont la table principale
      • Un enseignant est lié à chaque session
      • Un statusid est donné à chaque session. Par exemple: 0 - Terminé, 1 - Annulé
      • Les sessions sont regroupées en "packs" de taille arbitraire
    • Chaque pack est attribué à un client

J'ai "conçu" (plus comme griffonné) le schéma sur un morceau de papier, essayant de le maintenir normalisé à la 3ème forme. Je l'ai ensuite branché dans MySQL Workbench et cela m'a rendu tout joli:
( Cliquez ici pour un graphique en taille réelle )

texte alternatif
(source: maian.org )

Exemples de requêtes que je vais exécuter

  • Quels clients avec crédit restant sont inactifs (ceux sans cours prévu à l'avenir)
  • Quel est le taux de présence par client / département / division (mesuré par l'ID de statut dans chaque session)
  • Combien de cours un enseignant a-t-il eu en un mois
  • Signaler les clients qui ont un faible taux de fréquentation
  • Rapports personnalisés pour les départements RH avec des taux de présence des personnes dans leur division

Des questions)

  • Est-ce trop ingénieux ou suis-je sur la bonne voie?
  • La nécessité de joindre plusieurs tables pour la plupart des requêtes entraînera-t-elle une forte augmentation des performances?
  • J'ai ajouté une colonne «dernière session» aux clients, car ce sera probablement une requête courante. Est-ce une bonne idée ou dois-je garder la base de données strictement normalisée?

Merci pour votre temps

Bob l'éponge
la source
131
Cher étudiant CS de première année: continuez à utiliser StackOverflow. Votre question est intéressante, bien écrite et utile. En d'autres termes, vous êtes dans le top 1% des poseurs de questions.
Adam Crossland
Une division peut-elle contenir d'autres divisions? SI c'est le cas, un tableau "a" peut être utilisé pour relier la division à la division qui la contient.
Mark Schultheiss
Merci pour les aimables commentaires :) Mark Je vais devoir revoir la documentation de ce projet, mais je ne pense pas que nous ayons identifié ce cas. Merci de l'avoir signalé.
bob esponja
1
Je n'aime pas vos convictions de nommage de clé primaire. la table divisionsa une colonne nommée divisionid. Ne trouvez-vous pas cela redondant? Nommez-le simplement id. également vos noms de table, y compris _has_: je supprimerais cela et le nommerais par exemple cities_departments. vos DATETIMEcolonnes doivent être de type TIMESTAMPsauf s'il s'agit de valeurs saisies par l'utilisateur. Je pense que c'est une bonne idée d'avoir les tables citieset countries. vous pouvez rencontrer des problèmes pour limiter les tables à un seul status. envisagez d'utiliser un INTet effectuez des comparaisons au niveau du bit sur celui-ci afin que vous puissiez y donner plus de sens
james
@binnyb Il y a beaucoup d'arguments sur l' utilisation de id comme nom de la clé primaire que les gens devraient considérer avant de décider.
Jedi

Réponses:

42

Quelques réponses supplémentaires à vos questions:

1) Vous êtes à peu près sur la cible pour quelqu'un qui aborde un problème comme celui-ci pour la première fois. Je pense que les indications des autres sur cette question jusqu'à présent la couvrent à peu près. Bon travail!

2 & 3) La performance que vous obtiendrez dépendra en grande partie d'avoir et d'optimiser les bons index pour vos requêtes / procédures particulières et, plus important encore, le volume d'enregistrements. À moins que vous ne parliez de plus d'un million d'enregistrements dans vos tableaux principaux, vous semblez être sur la bonne voie pour avoir une conception suffisamment grand public pour que les performances ne soient pas un problème sur un matériel raisonnable.

Cela dit, et cela se rapporte à votre question 3, avec le début que vous avez, vous ne devriez probablement pas trop vous inquiéter de la performance ou de l'hyper-sensibilité à l'orthodoxie de normalisation ici. Il s'agit d'un serveur de rapports que vous créez, et non d'un backend d'application basé sur les transactions, qui aurait un profil très différent en ce qui concerne l'importance des performances ou de la normalisation. Une base de données sauvegardant une application d'inscription et de planification en direct doit tenir compte des requêtes qui prennent quelques secondes pour renvoyer des données. Non seulement une fonction de serveur de rapports est plus tolérante pour les requêtes complexes et longues, mais les stratégies pour améliorer les performances sont très différentes.

Par exemple, dans un environnement d'application basé sur les transactions, vos options d'amélioration des performances peuvent inclure la refactorisation de vos procédures stockées et structures de table au nième degré, ou le développement d'une stratégie de mise en cache pour de petites quantités de données couramment demandées. Dans un environnement de génération de rapports, vous pouvez certainement le faire, mais vous pouvez avoir un impact encore plus important sur les performances en introduisant un mécanisme de capture instantanée où un processus planifié s'exécute et stocke des rapports préconfigurés et vos utilisateurs accèdent aux données de capture instantanée sans stress sur votre niveau de base de données sur une par demande.

Tout cela est un discours de longue haleine pour illustrer que les principes de conception et les astuces que vous utilisez peuvent différer compte tenu du rôle de la base de données que vous créez. J'espère que c'est utile.

Tom Crowe
la source
1
1. Merci, c'est rassurant! 2 & 3. Je ne sais toujours pas comment fonctionnent les index, c'est quelque chose que j'ai prévu de lire. Si jamais nous avons le "problème" d'atteindre un million d'enregistrements, il y aura probablement un budget pour embaucher des développeurs expérimentés: P Merci pour la perspicacité dans les différents rôles de base de données qui existent, c'est tout nouveau pour moi et très intéressant à savoir. Je vais examiner les instantanés car ce que vous décrivez est essentiellement l'objectif final du projet.
bob esponja
Si vous comprenez les tableaux, les principes fondamentaux des indices sont assez faciles. Conceptuellement, un index peut être (et est souvent) implémenté comme une table avec très peu de colonnes dont le contenu est copié à partir de la table principale, et une référence à la table principale, dont les lignes sont triées par keot pour une accessibilité rapide. B + Tree est l'arrangement d'index le plus courant, mais les optimisations d'index sont là où les grands acteurs ont leurs technologies de différenciation, donc cela devient trouble si vous essayez d'appliquer l'analogie trop profondément.
pojo-guy
14

Vous avez la bonne idée. Vous pouvez cependant le nettoyer et supprimer certaines des tables de mappage (a *).

Ce que vous pouvez faire, c'est dans le tableau Départements, ajoutez CityId et DivisionId.

A part ça, je pense que tout va bien ...

Révérend Gonzo
la source
4
Je pense qu'il a besoin des tables de mappage s'il veut réutiliser une définition de département dans différentes divisions ou villes.
Jacob G
1
Oui, je suis d'accord ..... mais il semblait qu'un département ne pouvait être que dans une seule ville / division. Sinon, ce qu'il avait était définitivement correct.
Révérend Gonzo
J'ai un article wiki que j'ai écrit avec une "spécification" dans le bureau, je vais devoir le relire, mais Jacob G a raison, IIRC il y a quelques départements qui s'étendent sur les divisions. Un département RH du parent ACME pour les soins de santé ACME et les soins corporels ACME. Si je peux le simplifier, je le ferai certainement, merci pour la suggestion.
bob esponja
6

Les seuls changements que j'apporterais sont:
1- Changez votre VARCHAR en NVARCHAR, si vous allez à l'international, vous voudrez peut-être unicode.

2- Changez vos identifiants internationaux en GUID (uniqueidentifier) ​​si possible (cela pourrait être ma préférence personnelle). En supposant que vous arriviez finalement au point où vous avez plusieurs environnements (dev / test / staging / prod), vous souhaiterez peut-être migrer les données de l'un à l'autre. Les identifiants GUID facilitent considérablement la tâche.

3- Trois couches pour votre entreprise -> Division -> La structure du département peut ne pas être suffisante. Maintenant, cela peut être une ingénierie excessive, mais vous pouvez généraliser cette hiérarchie de manière à pouvoir prendre en charge n niveaux de profondeur. Cela rendra certaines de vos requêtes plus complexes, ce qui ne vaut peut-être pas le compromis. De plus, il se pourrait que tout client qui a plus de couches soit facilement «utilisable» dans ce modèle.

4- Vous avez également un statut dans la table des clients qui est un VARCHAR et qui n'a aucun lien avec la table des statuts. Je m'attendrais à un peu plus de clarté quant à ce que représente le statut du client.

Jacob G
la source
1- Merci, j'ai eu des problèmes avec les diacritiques et l'UTF8 pour lesquels j'allais poster une autre question. C'est peut-être le problème. 2- J'ai lu quelques autres questions ici sur SO avec beaucoup d'opinions contradictoires sur la question, je ferai plus de lecture sur le sujet. 3- Je vais en reparler avec mon père, en regardant la "spécification" que j'ai écrite et voir si c'est quelque chose que nous devrions examiner. - Suite du prochain commentaire
bob esponja
4- Je ne suis pas entré dans la question principale par souci de concision: le statut sur le client est de savoir s'il est actif (il reste des sessions) ou inactif (aucune session restante). Par plus de clarté, voulez-vous dire un nom plus descriptif pour le col? Par exemple, enrolment_status? Merci pour votre contribution.
bob esponja
re # 4- En plus de votre nom plus clair, s'il n'y a que deux états, actif / inactif, alors pourquoi ne pas simplement en faire une colonne de bits?
Jacob G
3
Pas d'accord sur les GUID, frémissez. Ils peuvent être horribles pour la performance. Ne les utilisez pas sauf si vous avez besoin de remplacer.
HLGEM
1
Les performances n'entrent en jeu que lorsque vous parlez de 10 millions de lignes dans une table. Si vous avez ce type de structure, vous pouvez atténuer cela avec des guides séquentiels et une indexation créative. Sinon, la «performance» est un atout rouge lors de la remise des GUID.
Jacob G
6

Il semble que vous conceviez avec un bon niveau de détail.

Je pense que les pays et les entreprises sont vraiment la même entité dans votre conception, tout comme les villes et les divisions. Je me débarrasserais des tables Pays et Villes (et Cities_Has_Departments) et, si nécessaire, ajouterais un drapeau booléen IsPublicSector à la table Companies (ou une colonne CompanyType s'il y a plus de choix que simplement Secteur Privé / Secteur Public).

De plus, je pense qu'il y a une erreur dans votre utilisation de la table des départements. Il semble que le tableau des départements serve de référence aux différents types de départements que chaque division client peut avoir. Si tel est le cas, il doit s'appeler DepartmentTypes. Mais vos clients (qui sont, je suppose, des participants) n'appartiennent pas à un TYPE de département, ils appartiennent à une instance de département réelle dans une entreprise. Dans l'état actuel des choses, vous saurez qu'un client donné appartient à un service RH quelque part, mais pas lequel!

En d'autres termes, les clients doivent être liés à la table que vous appelez Divisions_Has_Departments (mais que j'appellerais simplement Departments). Si tel est le cas, vous devez réduire les villes en divisions comme indiqué ci-dessus si vous souhaitez utiliser l'intégrité référentielle standard dans la base de données.

Larry Lustig
la source
Le tableau des pays est pour si / quand nous avons des clients qui opèrent dans plus d'un pays et ont un département RH différent pour chacun. De cette façon, nous pouvons créer des rapports avec des données provenant du pays dans lequel nous travaillons. Même chose pour les départements et les villes, je pense que nous avons un client qui a des départements RH distincts. pour les deux villes dans lesquelles ils ont des bureaux principaux. Ou du moins c'était le raisonnement, je vais m'asseoir et repenser pour voir s'ils sont vraiment nécessaires. Je n'avais pas pensé à CompanyType, je vais voir si c'est quelque chose que nous devons suivre.
bob esponja
RE: tableau des depts, ma pensée originale était de l'utiliser comme de vrais services, avec le nom du département comme type. Il ne m'était pas venu à l'esprit de n'avoir que des types de département, ce qui semble plus logique. A propos de savoir à quel département et à qui appartient quelqu'un, j'avais pensé que le fait de relier le département à une ville et une division (qui est liée à une entreprise) aurait fonctionné. Avais-je tort? Pour regrouper les villes en divisions, certaines divisions s'étendent sur plusieurs villes, et je pense peut-être même des pays. J'y reviendrai. Merci pour votre contribution.
bob esponja
5

Soit dit en passant, il convient de noter que si vous générez déjà des fichiers CSV et que vous souhaitez les charger dans une base de données mySQL, LOAD DATA LOCAL INFILE est votre meilleur ami: http://dev.mysql.com/doc/refman/5.1/ fr / load-data.html . Mysqlimport vaut également la peine d'être étudié, et est un outil en ligne de commande qui est fondamentalement un bon wrapper autour du chargement des fichiers de données.

jrheard
la source
3

La plupart des choses ont déjà été dites, mais je pense que je peux ajouter une chose: il est assez courant que les jeunes développeurs se préoccupent un peu trop des performances à l'avance, et votre question sur la jonction de tables semble aller dans cette direction. Il s'agit d'un anti-modèle de développement logiciel appelé « Optimisation prématurée ». Essayez de bannir ce réflexe de votre esprit :)

Une dernière chose: croyez-vous que vous avez vraiment besoin des tableaux «villes» et «pays»? Une colonne "ville" et "pays" dans le tableau des services ne suffirait-elle pas pour vos cas d'utilisation? Par exemple, votre application doit-elle répertorier les départements par ville et les villes par pays?

Hans Westerbeek
la source
1
Essayez comme je pourrais, il continue de prendre ove calcule le grand O de helloworld.c, optimise Les tableaux des villes et des pays se sont juste générés quand je suivais les étapes pour obtenir une base de données 3NF. Je suppose que l'avantage qu'ils offrent est la cohérence des noms de ville / pays. Comme si nous obtenons un client à Munich et pour une raison quelconque, quiconque entre un nouvel étudiant dans le système de planification décide de l'appeler Munich au lieu de Munich comme pour les étudiants précédents. Nous pourrions également avoir besoin de lister les départements par ville, je vais devoir vérifier. Merci.
bob esponja
2
L'optimisation dans la phase de conception d'une base de données est critique! L'optimisation n'est pas prématurée car les bases de données sont beaucoup plus difficiles à refacotr qu'elles ont des millions d'enregistrements.
HLGEM
1
Je n'ai pas dit qu'il ne devrait pas tester sa conception sous contrainte :)
Hans Westerbeek
3

Commentaires suivants basés sur le rôle de spécialiste en Business Intelligence / Reporting et gestionnaire de stratégie / planification:

  1. Je suis d'accord avec la direction de Larry ci-dessus. À mon humble avis, ce n'est pas tellement trop conçu, certaines choses semblent un peu hors de propos. Pour rester simple, je marquerais le client directement sur un ID d'entreprise, une description de département, une description de division, un ID de type de département, un ID de type de division. Utilisez l'ID de type de département et l'ID de type de division comme références aux tables de recherche et aux champs de rapport / analyse internes pour une cohérence à long terme.

  2. La table des packs contient la colonne "Crédit", cela ne devrait-il pas être lié à la table de base du client, donc si beaucoup de packs vous pouvez voir combien de crédit est dû pour les futures classes? L'application peut prendre en charge le calcul et le stocker de manière centrale dans la table Client.

  3. Les informations sur la société peuvent utiliser de nombreux autres champs, y compris l'adresse / le téléphone / etc. information. Je serais également prêt à ajouter dans les colonnes "DUN" D&B (Site / Branch / Ultimate) à long terme, Dun and Bradstreet (D&B) a un énorme catalogue de sociétés et vous trouverez plus tard sur la route leurs informations sont très utiles pour les rapports / analyses. Cela prendra en charge le problème de division multiple que vous mentionnez et vous permettra de regrouper leur hiérarchie pour les sous / divisions / branches / etc. de grands corps.

  4. Vous ne mentionnez pas le nombre d'enregistrements avec lesquels vous allez travailler, ce qui pourrait impliquer la mise en place d'une vaste initiative de développement qui aurait pu être effectuée plus rapidement et beaucoup moins de maux de tête avec un logiciel de "reporting" pré-emballé. Si vous ne traitez pas avec une grande base de données (<65 000) lignes, assurez-vous que MS-Access, OpenOffice (Base) ou les solutions de développement de rapport / application associées ne peuvent pas faire l'affaire. J'utilise moi-même un peu le logiciel gratuit APEX d'Oracle, il est livré avec leur base de données gratuite Oracle XE, il suffit de le télécharger sur leur site.

  5. FYI - Reporting insight: pour les grandes bases de données, vous avez généralement deux instances de base de données a) une base de données de transactions pour enregistrer chaque enregistrement détaillé. b) base de données de rapports (magasin de données / entrepôt de données) hébergée sur une machine distincte. Pour plus d'informations, recherchez sur Google Schéma étoile et Schéma flocon de neige.

Cordialement.

Volonté
la source
1. Voulez-vous dire ajouter toutes ces colonnes à la table client? Je pense que cela briserait la normalisation et rendrait difficile la cohérence, je ne suis pas sûr d'avoir bien compris cependant. 2. Les packs sont séquentiels, seul le pack le plus récent peut avoir un crédit en cours, donc pas besoin de suivre plusieurs packs. Recommanderiez-vous toujours de le stocker dans la table client dans ce cas? 3. Cela semble être très utile pour déterminer la structure des entreprises clientes, je vais y jeter un coup d'œil merci.
bob esponja
4. Je vais devoir vérifier le nombre de clients et de sessions que nous prévoyons d'avoir au cours de la prochaine année, mais il me semble possible que le tableau des sessions atteigne autant de lignes en un an environ. Je vais m'intéresser aux logiciels de reporting, cela ne m'est pas venu à l'esprit. 5. Il semble que ce soit la situation à laquelle je suis arrivé par accident; l'application web sera notre "base de données de transactions" et ce projet notre "base de données de repotage" :) Merci pour votre contribution.
bob esponja
1. Oui en ajoutant des colonnes "ID société, description de service, description de division, ID de type de département, ID de type de division" à la table client. Le client appartient à une entreprise, un type de service distinct (IT / Ops / Admin / etc.) Au sein d'une entreprise et un type de division distinct (secteurs d'activité Ventes / RH / Marketing). 2. Je pense simplement que le crédit est associé à un client ou à une entreprise et non au pack de sessions. Il s'agit d'une décision commerciale que vous pouvez prendre.
Le
Larry a également mentionné la combinaison de la société et du pays. Je suis totalement d'accord et reviens au point concernant la référence D&B. J'utiliserais un SiteID ou quelque chose d'unique pour autoriser plusieurs emplacements de la même entreprise, puis relierais les départements à l'un des SiteID uniques.
Will
2

Je souhaite répondre uniquement à la préoccupation selon laquelle la connexion à plusieurs tables entraînera un impact sur les performances. N'ayez pas peur de normaliser car vous devrez faire des jointures. Les jointures sont normales et attendues dans les bases de données relationnelles et elles sont conçues pour bien les gérer. Vous devrez définir des relations PK / FK (pour l'intégrité des données, cela est important à prendre en compte lors de la conception) mais dans de nombreuses bases de données, les FK ne sont pas automatiquement indexés. Puisqu'ils seront utilisés dans les jointures, vous voudrez certainement commencer par indexer le FKS. Les PK reçoivent généralement un index sur la création car ils doivent être uniques. Il est vrai que la conception de l'entrepôt de données réduit le nombre de jointures, mais généralement, on ne parvient pas à l'entreposage de données tant que l'on n'a pas besoin d'accéder à des millions d'enregistrements dans un seul rapport. Même alors, presque tous les entrepôts de données commencent par une base de données transactionnelle pour collecter les données en temps réel, puis les données sont déplacées vers l'entrepôt selon un calendrier (nocturne ou mensuel ou selon les besoins de l'entreprise). C'est donc un bon début même si vous devez concevoir un entrepôt de données ultérieurement pour améliorer les performances des rapports.

Je dois dire que votre design est impressionnant pour un étudiant CS de première année.

HLGEM
la source
1

Ce n'est pas trop conçu, c'est ainsi que j'aborderais le problème. Rejoindre est très bien, il n'y aura pas beaucoup de performances (c'est complètement nécessaire à moins que vous ne dénormalisiez la base de données, ce qui n'est pas recommandé!). Pour les statuts, voyez si vous pouvez utiliser un type de données enum à la place pour optimiser cette table.

Chris Dennett
la source
les énumérations sont mauvaises. Chaque fois que vous devez étendre l'énumération, vous devez reconstruire votre table - ce qui est OK jusqu'à ce que votre table atteigne plusieurs Go.
Martin
Merci pour la contribution et la suggestion de Chris, je craignais de créer un monstre trop complexe. Martin, les statuts sont assez bien définis et statiques: essentiellement 0-classe complète, 1 classe annulée, 2-ne s'est pas produite. Je pense que ces trois couvrent tout résultat possible d'une classe. Est-ce toujours une mauvaise idée d'utiliser des énumérations dans ce cas?
bob esponja
Cela semble parfait pour un enum, dans mon esprit. Tous les résultats possibles sont satisfaits à l'avance. Un int est également très bien que vous pouvez représenter par une énumération ou des entrées statiques dans votre application. Cela n'a pas vraiment d'importance :) Les énumérations sont plus agréables à regarder si vous modifiez votre base de données à l'aide d'un outil.
Chris Dennett
les énumérations peuvent être problématiques (peut-être que le mot mal est trop fort) lorsque vous avez de grandes tables qui doivent être en ligne 24h / 24 et 7j / 7 et que l'énumération doit être modifiée. Étant donné que vous repeupler les tableaux à partir de zéro - ne vous inquiétez pas. Étant donné un ensemble de données suffisamment petit, vous pourriez tout aussi bien utiliser des chaînes.
Martin
1

J'ai travaillé dans le domaine de la formation / école et j'ai pensé que je ferais remarquer qu'il y a généralement une relation M: 1 entre ce que vous appelez des "sessions" (instances d'un cours donné) et le cours lui-même. En d'autres termes, votre catalogue propose le cours ("Espagnol 101" ou autre), mais vous pouvez en avoir deux instances différentes au cours d'un même semestre (Tu-Th enseigné par Smith, Wed-Fri enseigné par Jones).

En dehors de cela, cela semble être un bon début. Je parie que vous constaterez que le domaine client (graphiques menant à des "clients") est plus complexe que vous ne l'avez modélisé, mais n'allez pas trop loin avec cela jusqu'à ce que vous ayez des données réelles pour vous guider.

Larry OBrien
la source
Si je vous ai bien compris, ce n'est pas tout à fait le cas. Les "cours" ne sont que des groupes de sessions ultérieures. Ce n'est pas un système semestriel traditionnel. Je ne peux penser à rien d'autre qui pourrait être ajouté au domaine client, en avez-vous un exemple? De plus, j'étais inquiet d'être déjà allé trop loin avec la complexité, content que ce ne soit pas le cas :) Merci pour votre contribution.
bob esponja
0

Quelques choses me sont venues à l'esprit:

  1. Les tables semblaient orientées vers le reporting, mais ne géraient pas vraiment l'entreprise. Je pense que lorsqu'un client s'inscrit, il y a essentiellement une commande passée pour le client participant à une liste de sessions, et cette commande peut concerner plusieurs employés dans une même entreprise. Il semblerait qu'un tableau de "commandes" soit vraiment au centre de votre système et conduise votre capture de données et vos éventuels rapports. (Comparez les documents papier que vous avez utilisés pour gérer l'entreprise avec la conception de votre base de données pour voir s'il existe une correspondance logique.)

  2. Les entreprises n'ont souvent pas de divisions. Les employés changent parfois de division / département, peut-être même en milieu de session. Les entreprises ajoutent / suppriment / renomment parfois des divisions / départements. Assurez-vous que le possible changement de contenu en temps réel de vos tableaux ne rend pas les rapports / regroupements ultérieurs difficiles. Avec autant de données de contact réparties sur autant de tableaux, vous devrez peut-être appliquer une validation de saisie des données très stricte pour garder vos rapports significatifs et inclusifs. Par exemple, lorsqu'un nouveau client est ajouté, s'assurer que son entreprise / division / département / ville correspond aux mêmes valeurs que ses collègues.

  3. Le concept de "packs" n'est pas clair du tout.

  4. Étant donné que vous indiquez qu'il s'agit d'une petite entreprise, il serait surprenant que les performances soient un problème, compte tenu de la vitesse et de la capacité des machines actuelles.

joe snyder
la source