MySQL 架构:空列与连接
我有一个应用程序,其中有重复事件。 因此,事件可以按天重复,“每 n 天”,按周重复,“每 n 周周一/周二/周三/等”,按月重复,“每 n 个月的第一、第二、第三等”。
从表格设计的角度来看,处理这个问题的最佳方法是什么? 我可以想到两种方法,但我不确定哪种方法更好。
1) 上述内容共 5 列,其中 1 列表示当天情况,各 2 列表示周和月。 那些没有被使用的将是空的。 在我的应用程序中,我可以看到空值并选择忽略它们。
2)有第二个表,例如 events_dateinfo 或其他表,我将根据该表加入查询。
看起来选项 2 可能更加“标准化”,但对于如此简单的事情,您是否觉得它太过分了? 另外,如果我选择选项 2,有没有办法将行转换为列 - 也就是说,为特定事件选择 2 周属性并将它们视为列?
I have an application where I'll have repeating events. So an event can repeat by day, "every n days", by week, "every n weeks on Mon/Tue/Wed/etc", and by month, "every n months on the 1st,2nd,3rd,etc".
What is the best way to handle this from a table design perspective? I can think of two ways but I'm not sure which one is better.
1) 5 columns for the above, 1 for the day case and 2 each for week and month. Whichever ones are not being used would be null. In my application I could see the nulls and choose to ignore them.
2) Have a second table, say events_dateinfo or something, against which I'd JOIN for the query.
Seems like option 2 is probably more 'normalized' and what not, but does it strike you as overkill for such a simple thing? Also, if I were to go option 2, is there a way to translate rows into columns - that is, select the 2 week attributes for a specific event and have them treated as columns?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果我理解正确的事件可以有超过 1 个时间表(这就是为什么你想要“将行转换为列”)。
在这种情况下,您需要的不是 2 个而是 3 个表; 第三个必须是联结表。 如果将来需要,您可以使用此方案轻松添加新的时间表。
所以,像这样:
据我所知,MySQL 中没有 PIVOT 可能性,但您可以在 SELECT 中使用 GROUP_CONCAT() 函数; 每个事件占一行,一个事件的所有时间表都将在一列中。
If I understood right event can have more than 1 schedule (this is why you want " to translate rows into columns ").
You will need not 2 but 3 tables in this case; third one must be junction table. You can easily add new schedules if you need in the future with this scheme.
So, something like this:
There isn't PIVOT possibility in MySQL as I know, but you can use GROUP_CONCAT() function in SELECT; it'll be one row per event and all schedules for one event will be in one column.
我更愿意处理这种标准化,一个表中的事件,以及另一个表中的事件重现。
以适当的方式处理索引,您可以通过视图处理数据请求,或者如果数据变大,可以作为带有触发器的审计表来处理。
I would prefer to handle this normallized, The events in one table, and the event recurrency in another.
Handling the indexes in a appropriate way, you can handle the request for data through views, or if data gets larger, as an audit table with triggers.