J'ai plusieurs tables telles que chacun de ceux-ci a une valeur par défaut, par exemple La valeur par défaut est Je voudrais enregistrer ces valeurs par défaut dans une base de données (afin que l'utilisateur puisse les modifier). Je pensais ajouter Puis je pensais que le meilleur serait d'avoir par défaut qui contiendra toutes les valeurs par défaut. Cette table aura 1 rangée et n colonnes, où n est le numéro des valeurs par défaut: mais, cela ne semble pas être la meilleure approche car la structure de la table change Lorsqu'une nouvelle valeur par défaut est ajoutée. Quelle serait la meilleure approche pour stocker les valeurs par défaut? acheteurs , magasins , marques , money_collectors , etc david , la boutique est ebay , etc. iS_Default colonne sur chacune des tables, mais elle Semble être inefficace car une seule ligne de chaque table peut être la valeur par défaut.
5 Réponses :
Vous devez plutôt créer une table avec deux colonnes et n lignes de cette façon, vous pouvez ajouter de nouvelles valeurs sans avoir à modifier la structure de la table
Quels types doivent être les colonnes?
Mais si certaines tables contiennent des chiffres ou des booléens?
Ceci est un EAV classique. Ce qui ne serait pas horrible dans ce cas, mais est un anti-motif et doit être évité.
@Stephanie Qu'est-ce qui a tellement mal avec ça? Pourriez-vous donner un lien vers un article, s'il vous plaît. La seule chose qui vient à l'esprit est un problème avec divers formats de date
Stackoverflow.com/Questions/3679376/database-design-Question / ...
Comme je l'ai dit, avec une table pour simplement par défaut, cela commence à ressembler à un registre Windows ... C'est juste une liste de paires de valeurs de clé. Dans ce cas, une table de style EAV ne serait pas horrible. Mais puisque je sais comment beaucoup de programmeurs pensent; Une fois que vous l'avez fait une fois, vous le mettez dans plus d'endroits où vous ne devriez pas. ;-)
Il est difficilement EAV, quand vous avez un = const = 'DefaultValue'. :) EAV est en effet une solution tentante au premier coup d'œil et un Horryfing une fois que vous êtes profondément compris. Il a ses utilisations, mais je conviens que cela devrait être évité si possible (juste pas en faveur des solutions encore pires). Dans ce cas particulier, une table de la valeur clé devrait fonctionner très bien dans l'OMHO.
Qu'il s'agisse de la valeur clé ou de la valeur d'attributs qui est toujours un EAV. Mais en général, je pense que nous ne sommes pas trop éloignés.
C'est une valeur clé incontrôlée, et c'est hideux
Et si vous créez un XML, puis stockez ce XML dans la table dans une colonne XML. La colonne XML contiendrait le XML et le XML pourrait avoir des étiquettes de tables et un sous-node des valeurs par défaut.
juste pour être clair.
Le meilleur moyen est d'une colonne sur chaque tableau qui dépose la source de.
"Ne devrais-je pas m'inquiéter de l'espace quand
enregistrer des données dans une base de données? "
La réponse courte est non. La réponse la plus longue est ce que vous devriez vous inquiéter est la performance. Se concentrer sur l'espace vous mènera à faire de très mauvaises choses.
mauvaises choses que vous allez faire si l'espace est une préoccupation.
Supposons qu'il y ait 50 magasins (cochez la case
avec 50 valeurs possibles). Dans ce
cas, pour stocker le magasin par défaut vous
besoin de 50 champs booléens,
Eh bien c'est laissez-moi vous demander ceci. Si vous avez créé une table avec 1 colonne de date et insérée 1 ligne, combien d'espace utiliseriez-vous sur le disque?
Si vous avez dit un 7 ou 8 octets, alors vous êtes éteint d'environ 1000 fois.
La plus petite unité d'espace disque est un bloc. Les blocs sont typiques de 8 kb (la peut être aussi petite que 2 Ko aussi grande que 32 Ko, en général (pas de nitpicking ici, les limites réelles sont sans importance))
Disons que vous avez des blocs de 8kb puis votre 1 colonne, 1 table de rangée prend 8 Ko. Si vous insérez 999 lignes supplémentaires, cela prendra toujours 8 Ko. (encore une fois de nitpicking il y a des frais générales par bloc et par rangée - c'est un exemple)
Ainsi, dans votre table de recherche avec 50 noms de magasins, la probabilité que l'ajout de 50 octets à la taille de la table vous oblige à se développer de 1 bloc à 2 est mince à néant et complètement non pertinent.
D'autre part, votre table par défaut prendra certainement au moins un bloc supplémentaire.
Mais le pire frappé à Vous avez donc enregistré exactement l'espace zéro et doublé votre trafic réseau.
Vous voyez ce que je dis.
Une autre raison cruciale d'arrêter de vous inquiéter de l'espace est d'abandonner la clarté. Pensez au développeur que vous allez embaucher pour exécuter cette application. Quand il rejoint l'équipe et regarde la base de données, imaginez les deux scénarios.
Vous lui demandez de construire un nouveau pour une liste déroulante pour «magasin».
Dans le scénario 1 Il trouve la table de magasin, file la liste déroulante vers une simple requête de la table et utilise le champ de défaute_value pour sélectionner la valeur initiale.
Dans le scénario 2, sans une formation, comment savoir chercher une table séparée? Peut-être qu'il verrait la table mais au moment où vous embauchez, votre Datamodel a maintenant des centaines de tables.
Encore une fois, un peu conçu mais le point est saillant. La clarté dans la base de données est bien, vaut bien un octet par ligne.
trucs techniques
Je ne suis pas un gars mysql mais à Oracle, une colonne nulle à la fin d'une ligne ne prend aucun espace supplémentaire. Dans Oracle, j'utiliserais un Varchar2 (1) et laissez-la = défaut et laissez les autres null. Cela aurait l'effet sur l'utilisation d'un total d'octets d'addition et non par ligne. YMMV avec MySQL, vous pouvez poser cette question séparément si vous ne pouvez pas télécharger Google la réponse.
Mais le temps de s'inquiéter de cela est sur des millions de rangées, pas des centaines. Toute table qui nourrit une liste déroulante ne sera jamais assez grosse pour commencer à s'inquiéter d'octets supplémentaires.
Dans MySQL Null Varchar (N <= 255) prend un octet. Tinyint (qui est synonyme de Boolean dans MySQL) fera aussi bien.
Vous répondez à un commentaire, pas à la question.
Merci mchl. D'accord. La question est de savoir quelle est la meilleure façon de stocker une valeur par défaut et c'est la même table avec une colonne. Le commentaire a éliminé l'une des solutions (le meilleur) et comprendre l'opposition de l'OP à cette solution est essentielle pour une réponse / une explication solide.
Vous pouvez créer une table de catalogue
Qu'est-ce que vous essayez de stocker n'est pas des informations métadonnées. Tout d'abord, je n'entraînerai donc pas un magasin de données externe pour stocker ces données. (Couplé avec code supplémentaire)
Je suppose que vous avez une logique de génération de séquence PK (sous votre contrôle). Je vais attribuer un numéro magique X et je vais insérer un enregistrement dans chaque table avec _ID = x comme valeur par défaut. Donc, si vous souhaitez montrer à l'utilisateur la valeur par défaut, vous pouvez gérer votre requête de manière uniforme ou vous pouvez gérer cela dans la logique d'application lors de l'insertion. La bonne chose à propos de ceci est, vous avez accès à la valeur par défaut tout le temps et sans écrire une logique supplémentaire et la logique de maintenance de la valeur par défaut d'une table peut être maintenue à l'aide du même code (Modèle;) (Des leçons W3C apprises des informations de schéma de modélisation de XML à l'aide de DTD.)
Seuls les captures sont que cette logique doit être explicite soit explicite soit en utilisant une documentation prolongée, soit difficile d'utiliser un déclencheur.
Tout d'abord, que fait la valeur par défaut? Deuxièmement, c'est une valeur par défaut par table ou une par table par utilisateur? Lorsque vous dites (afin que l'utilisateur puisse les modifier), il semble que chaque utilisateur ait un ensemble de défauts. Ou voulez-vous dire qu'un utilisateur administrateur pourrait changer la valeur par défaut? Dernier pourquoi êtes-vous opposé à une colonne IS_DEFAULT? Quel serait le problème avec ça?
Dans mon cas, chaque table stocke toutes les valeurs possibles d'une boîte de sélection. Il existe une valeur par défaut dans chaque boîte de sélection (ou nil s'il n'y a pas de valeur par défaut). Cela ne me dérange pas des utilisateurs. Supposons qu'il n'y a qu'un seul utilisateur (comme admin) qui peut modifier la valeur par défaut. Concernant la colonne
IS_DEFAULT : Supposons que 50 magasins (sélectionnez la case avec 50 valeurs possibles). Dans ce cas, pour stocker la boutique par défaut, vous avez besoin de 50 champs booléens, plutôt que 1. En d'autres termes, je ne veux pas dépenser de la place. Je ne devrais-je pas m'inquiéter de l'espace lors de la sauvegarde des données dans une base de données?Comment voulez-vous que la valeur par défaut fonctionne? Est-ce pour l'interface utilisateur, de sorte que les magasins sélectionnent la boîte par défaut sur eBay? Ou est-ce pour la base de données de la base de données, de sorte que vous stockiez eBay pour le magasin si l'utilisateur n'a pas sélectionné de boutique?