Dans le projet où je travaille, j'ai vu cette structure dans la base de données, et je vous demande à tous, quel enfer de la modélisation est-ce?De quel type de structure s'agit-il?
TableX
Columns: isMonday, BeginingHourMonday, EndHourMonday, isTuesday, BeginingHourTuesday, EndHourTuesday and so on...
Est-ce que c'est no-sql? Je n'ai pas demandé à la personne qui a créé parce que j'ai honte: $
Bye.
Ceci est appelé une table de calendrier.
Il s'agit d'une approche très commune et incroyablement utile pour traiter et résoudre un grand nombre de requêtes liées à la date et à l'heure. Il vous permet de rechercher, trier, grouper ou extraire des données de manière intéressante et intelligente.
ce sont des données totalement normalisées. pas de type sql. Je me demande juste pourquoi le mois n'est pas inclus. cela pourrait augmenter le facteur de dé-normalisation.
@Brian Gideon a raison. Ainsi est @iamgopal. Et moi aussi, quand je dis "cela dépend de la nature des données modélisées et stockées dans la base de données".
Si c'est une liste de jours avec certains attributs/propriétés pour chaque jour, alors oui, je l'appellerais dénormalisé - et 9 fois sur 10 (ou plus) ce sera probablement le cas. (Je me souviens d'une base de données avec 13 colonnes, une pour chaque mois de l'année et une pour le total, et à la fin de l'année, l'utilisateur a ajouté 13 colonnes de plus pour l'année suivante. S'il s'agit d'une description des heures de travail, par exemple, dans une semaine, où chaque fois que les données sont demandées toujours nécessitent les informations pour chaque jour de la semaine, alors la ligne représenterait une "unité" "de données (chaque colonne dépend de la clé primaire de la table et de tout cela), et il serait contre-productif de diviser les données en plus petites pièces. Et, bien sûr, il pourrait s'agir d'une combinaison des deux données qui étaient initialement normalisées jusqu'à une ligne par jour, puis dénormalisées intentionnellement pour des raisons de performances. Peut-être que 9 fois sur 10, ils ont besoin d'une semaine d'informations, et l'analyse a montré des gains de performance massifs en concaténant ces données en une seule ligne? Comme c'est le cas, sans plus d'informations sur l'utilisation et rationnelle, je suis en faveur de @iamgopal, et l'upvoting lui.
Ressemble à une structure d'une feuille de temps pour une semaine donnée.
Si normalisé, il pourrait ressembler à
colonnes: jour, startHour, endHour
Lorsque cela est converti en un tableau croisé dynamique dans Excel, vous aurez une sorte de feuille de temps d'une structure, ce qui est bon pour les écrans d'entrée/vues (par opposition à la création d'une vue avec une structure normalisée).
En regardant cette table. Je ne vois aucune bonne raison de le faire, même pour une raison de performance.
Voyons voir, si je change le isMonday, isTuesday, etc à ID_Day J'ai toujours la même vitesse et la même logique. Et si je change le BeginingHourMonday en StartHour et le EndHourMonday en EndHour, j'ai toujours le même effet.
J'ai toujours le jour de la semaine et l'heure de début et de fin et c'est l'idée de base que je reçois de la struture de la table. Peut-être qu'il y a quelque chose que je ne vois pas.
Observe
sont les tables 'isMonday' et' isTuesday'? –
Veuillez élaborer sur cette structure. Quelles sont les tables impliquées? Quel est le contexte et le but de ce tableau en particulier (journal des transactions ex, suivi des heures de travail, description de la période)? La réponse à votre question dépend fortement de la structure et de l'utilisation précises. –