Quelle est la meilleure conception de firebase database: plus de tables ou plus de colonnes?

J’ai quelques règles simples à suivre lorsque je conçois des bases de données, que je pense pouvoir utiliser pour prendre des décisions comme celle-ci …

1. Favoriser la normalisation. La dénormalisation est une forme d’optimisation, avec tous les compromis nécessaires, et en tant que telle, elle doit être abordée avec une attitude de YAGNI .
2. Assurez-vous que le code client référençant la firebase database est suffisamment dissocié du schéma pour que le remaniement ne nécessite pas une refonte majeure du ou des clients.
3. N’ayez pas peur de dénormaliser quand il offre un avantage évident en termes de performances ou de complexité des requêtes.
4. Utilisez des vues ou des tables en aval pour implémenter la dénormalisation plutôt que de dénormaliser le cœur du schéma, lorsque le volume de données et les scénarios d’utilisation le permettent .

Le résultat habituel de ces règles est que la conception initiale favorisera les tableaux sur colonnes, en mettant l’accent sur l’élimination de la redondance. Au fur et à mesure de l’avancement du projet et de l’identification des points de dénormalisation, la structure globale évoluera vers un équilibre qui compromet la redondance et la prolifération des colonnes en échange d’autres avantages précieux.

Je plaiderais en faveur d’un plus grand nombre de tables, mais seulement jusqu’à un certain point. En utilisant votre exemple, si vous séparez les informations de votre utilisateur en deux tables, disons UTILISATEURS et ADRESSE, vous avez la possibilité d’avoir plusieurs adresses par utilisateur. Une application évidente est un utilisateur qui a des adresses de facturation et d’expédition distinctes.

L’argument en faveur d’une table CITY séparée serait que vous ne devez stocker le nom de chaque ville qu’une seule fois, puis vous y référer lorsque vous en avez besoin. Cela réduit la duplication, mais dans cet exemple, je pense que c’est exagéré. Il peut être plus efficace en termes d’espace, mais vous payez le prix en jointures lorsque vous sélectionnez des données dans votre firebase database.

Cela ne ressemble pas tellement à une question sur les tables / colonnes, mais à la normalisation. Dans certaines situations, le degré de normalisation est élevé (“plus de tables” dans ce cas) est bon et propre, mais il faut généralement un grand nombre de JOIN pour obtenir des résultats pertinents. Et avec un dataset suffisamment important, cela peut ralentir les performances.

Jeff a écrit un peu à ce sujet concernant la conception de StackOverflow. Voir aussi l’article que Jeff a associé à Dare Obasanjo .

Une conception entièrement normalisée (c.-à-d. “Plus de tables”) est plus flexible, plus facile à gérer et évite la duplication des données, ce qui signifie que l’intégrité de vos données sera beaucoup plus facile à appliquer.

Ce sont des raisons puissantes de normaliser. Je choisirais d’abord de normaliser, puis de ne dénormaliser que des tables spécifiques après avoir constaté que la performance devenait un problème.

Mon expérience est que dans le monde réel, vous n’atteindrez pas le stade où la dénormalisation est nécessaire, même avec de très grands ensembles de données.

Cela dépend de la saveur de votre firebase database. MS SQL Server, par exemple, a tendance à préférer des tables plus étroites. C’est aussi l’approche la plus “normalisée”. D’autres moteurs pourraient préférer le contraire. Les mainframes ont tendance à tomber dans cette catégorie.

Chaque table ne doit inclure que des colonnes appartenant à l’entité identifiée de manière unique par la clé primaire. Si toutes les colonnes de la firebase database sont toutes des atsortingbuts de la même entité, vous n’avez besoin que d’une seule table avec toutes les colonnes.

Si l’une des colonnes peut être NULL, vous devrez placer chaque colonne nullable dans sa propre table avec une clé étrangère dans la table principale afin de la normaliser. Il s’agit d’un scénario courant. Par conséquent, pour un design plus propre, vous appendez probablement plus de tables que de colonnes aux tables existantes. De plus, en ajoutant ces atsortingbuts facultatifs à leur propre table, ils n’auront plus besoin d’autoriser les valeurs NULL et vous éviterez ainsi de nombreux problèmes liés à NULL.

La firebase database multi-tables est beaucoup plus flexible si l’une de ces relations individuelles peut devenir une à plusieurs ou plusieurs à l’avenir. Par exemple, si vous avez besoin de stocker plusieurs adresses pour certains clients, c’est beaucoup plus facile si vous avez une table client et une table d’adresses. Je ne peux pas vraiment voir une situation où vous pourriez avoir besoin de dupliquer certaines parties d’une adresse, mais pas d’autres, donc les tables d’adresses, de villes, d’états et de zip peuvent être un peu trop hautes.

Comme tout le rest: ça dépend.

Il n’y a pas de règle ssortingcte concernant le nombre de colonnes et le nombre de tables.

Si vos clients doivent avoir plusieurs adresses, une table distincte est alors utile. Si vous avez une très bonne raison de normaliser la colonne City dans sa propre table, alors cela peut aller aussi, mais je ne l’ai pas vu auparavant parce que c’est un champ de forme libre (généralement).

Une conception de table lourde et normalisée est efficace en termes d’espace et ressemble à un manuel, mais peut devenir extrêmement complexe. Cela semble intéressant jusqu’à ce que vous ayez à faire 12 jointures pour obtenir le nom et l’adresse d’un client. Ces conceptions ne sont pas automatiquement fantastiques en termes de performances, ce qui compte le plus: les requêtes.

Évitez la complexité si possible. Par exemple, si un client ne peut avoir que deux adresses (pas arbitrairement beaucoup), il peut être judicieux de les conserver dans une seule table (CustomerID, Name, ShipToAddress, BillingAddress, ShipToCity, BillingCity, etc.).

Voici le post de Jeff sur le sujet.

Avoir des tableaux avec moins de colonnes présente des avantages, mais vous devez également examiner votre scénario ci-dessus et répondre aux questions suivantes:

Le client sera-t-il autorisé à avoir plus d’une adresse? Sinon, une table séparée pour l’adresse n’est pas nécessaire. Si tel est le cas, un tableau distinct devient utile, car vous pouvez facilement append plus d’adresses au besoin, où il devient plus difficile d’append plus de colonnes à la table.

Je considérerais la normalisation comme la première étape, donc les villes, les comtés, les états, les pays seraient meilleurs en tant que colonnes séparées … la puissance du langage SQL, avec DBMS-es d’aujourd’hui, vous permet de regrouper vos données plus tard dans une autre vue non normalisée.

Lorsque le système est en cours de développement, vous pourriez envisager de «neutraliser» une partie si vous considérez cela comme une amélioration.

Je pense que l’équilibre est dans ce cas. S’il est logique de mettre une colonne dans une table, alors mettez-la dans la table, si ce n’est pas le cas, alors ne le faites pas. Votre approche de collègues aiderait certainement à normaliser la firebase database, mais cela pourrait ne pas être très utile si vous devez joindre 50 tables ensemble pour obtenir les informations dont vous avez besoin.

Je suppose que ma réponse serait, utilisez votre meilleur jugement.

Il y a plusieurs facettes à cela, mais du sharepoint vue de l’efficacité des applications, les tableaux peuvent être plus efficaces par moments. Si vous avez quelques tables avec un tas de colonnes chaque fois que la firebase database effectue une opération, elle risque de se verrouiller, plus de données sont rendues indisponibles pendant la durée du locking. Si les verrous sont transférés à la page et aux tables (et si tout va bien pas aux tables :)), vous pouvez voir comment cela peut ralentir le système.

Hmm.

Je pense que c’est un lavage et dépend de votre modèle de conception particulier. Éliminez définitivement les entités qui ont plus de quelques champs dans leur propre table, ou les entités dont la composition changera probablement à mesure que les exigences de votre application changent (par exemple – je prendrais en compte l’adresse de toute façon, car il y a beaucoup de champs, mais je Faites-le surtout si vous pensiez que vous auriez besoin de gérer des adresses de pays étrangers, ce qui peut être différent. Même chose avec les numéros de téléphone).

Cela dit, quand vous avez le travail, gardez un œil sur les performances. Si vous avez créé une entité qui nécessite des jointures volumineuses et coûteuses, il est peut-être préférable de repositionner cette table dans l’original.

Les requêtes utilisant le moins de colonnes possible présentent d’énormes avantages. Mais la table elle-même peut avoir un grand nombre. Jeff dit aussi quelque chose à ce sujet.

En gros, assurez-vous de ne pas demander plus que nécessaire lorsque vous effectuez une requête – la performance des requêtes est directement liée au nombre de colonnes que vous demandez.

Je pense que vous devez examiner le type de données que vous stockez avant de prendre cette décision. Avoir une table d’adresses est génial mais seulement si la probabilité que plusieurs personnes partagent la même adresse est élevée. Si chaque personne a des adresses différentes, conserver ces données dans une table différente introduit simplement des jointures inutiles.

Je ne vois pas l’avantage d’avoir une table de ville à moins que les villes en elles-mêmes ne soient des entités dont vous vous souciez dans votre application. Ou si vous souhaitez limiter le nombre de villes disponibles pour vos utilisateurs.

En fin de compte, des décisions comme celle-ci doivent prendre en compte l’application elle-même avant de commencer à prendre des mesures d’efficacité. IMO.

Lorsque vous concevez votre firebase database, vous devez être aussi proche que possible de la signification des données et NON de votre application!

Une bonne conception de firebase database devrait durer plus de 20 ans sans modification.

Un client peut avoir plusieurs adresses, c’est la réalité. Si vous avez décidé que votre application est limitée à une adresse pour la première version, cela concerne la conception de votre application et non les données!

Il est préférable d’avoir plusieurs tables au lieu de plusieurs colonnes et d’utiliser la vue pour simplifier votre requête.

La plupart du temps, vous rencontrerez des problèmes de performances avec une firebase database, mais pas avec la complexité de votre requête.

D’abord, normalisez vos tables. Cela garantit que vous évitez les données redondantes, vous donnant moins de lignes de données à parsingr, ce qui améliore vos requêtes. Ensuite, si vous rencontrez un point où les tables normalisées que vous rejoignez entraînent un long processus de traitement de la requête (clause de jointure coûteuse), dénormalisez-la là où elle convient.

Bon de voir autant de réponses inspirantes et bien fondées.

Ma réponse serait (malheureusement): cela dépend.

Deux cas de figure: * Si vous créez un modèle de données qui doit être utilisé pendant de nombreuses années et qui doit par conséquent subir de nombreux changements futurs: optez pour plus de tables et moins de lignes et une normalisation assez ssortingcte. * Dans d’autres cas, vous pouvez choisir entre plusieurs lignes sans tables ou moins de lignes avec plus de tables. Surtout pour les personnes relativement nouvelles sur le sujet, cette dernière approche peut être plus intuitive et facile à comprendre.

La même chose est valable pour le choix entre l’approche orientée object et d’autres options.