为什么将实体分组为“1,3,41”？实体字段（！！！）比GROUP表和外键差？
是的，所以问题看起来像是我在开玩笑，但事实证明，有些“建筑师”坚信第一选择。
简介： 某个 X 团队从 Y 团队那里获得了一个项目，但该项目失败了。 X 团队应该完成该项目并添加更多功能。但客户从 Y 团队中留下了一些人来帮助开发该项目。客户确信 Y 知道要做什么，因为大部分功能都在工作。这是事实。 X 团队决定稍微更改数据库架构以便能够添加新功能，并且还决定更改分组策略。
域：有一些实体应该分组。 方法 1 是在表 ENTITY 中添加字段“group”，并在其中写入实体的 id，例如“1,3,41”。这意味着实体 1 的列中有“1,3,41”，实体 3 的列中有“1,3,41”，41 也是如此。方法 2 是拥有另一个表“GROUP”以及表“ENTITY”中的外键到“GROUP”。
我很乐意帮助 X 团队。
我的论点：
1) 如果团队（将来）需要一些属性，那么将其放在一个表行中会更容易，并且不要在许多表中重复该数据实体。
2）还解析字段以获取链接实体列表，然后获取它们将来可能很难支持。在这种情况下，最好使用包含外键的连接语句。
3）将来转向ORM可能会很痛苦。
4) ...你的建议...
主要问题是客户非常依赖左架构师，至少他知道领域。
问题：还有哪些其他论据可以帮助 X 团队？ Y 有什么相反的东西吗？ （实际上他建议复制粘贴他的代码，因为它正在工作......）
Yeah, so question looks like I'm kidding, but it turns out that there are "architects" that are convinced about first choice.
Introduction:
Some team X got a project from team Y, that have failed project. Team X should finish the project and add more features. But Customer left some guys from team Y to help develop the project. Customer is sure that Y knows what to do, since much of the functionality is working. That is truth. Team X decided to slightly change database schema to be able to add new features also it decided to change grouping strategy.
Domain: There are some Entities that should be grouped. Approach 1 is to have field 'group' in table ENTITY and write there ids of Entities like "1,3,41". This means that entity 1 has "1,3,41" in its column and entity 3 has "1,3,41" and the same for 41. Approach 2 is to have another table 'GROUP' and foreign key in table 'ENTITY' to the 'GROUP'.
I would love to help team X.
My arguments:
1) If group will need (in future) some properties it would be much easier to have this in one table row and do not duplicate that data in many entities.
2) Also parsing field to get list of linked entities and then fetching them could be difficult to support in future. Joining statements that include foreign keys is preferable in this case.
3) Moving to ORM in future might be painful.
4) ... your suggestion ...
The main problem is that customer relies on left architect very much, at least he knows domain.
Question: What are other arguments to help team X? Are there anything that Y will have in opposite? (Actually he suggest to copy-paste his code, since it is working...)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
两个词：参照完整性。
Two words: referential integrity.
该团队可能会使用动态 SQL 进行搜索。他们只是形成语句
此代码将运行得足够快，但支持该结构并将数据保持在实际状态是另一个问题。
That team may use dynamic sql for search. They just form statement
This code will work fast enough, but support of that structure and keep data in actual state is another question.
X团队可以实现自己的功能，并制作与原始表同名的sql视图，用于只读操作（报告）。但他们可以更改用于向组添加项目或从组中删除项目的所有存储过程。也用于获取特定群体的物品。
以这种方式将提供向后兼容性。任何对存储过程的调用都会导致sql视图发生变化。每次锁定原始表时，该视图也会被锁定。
同时他们将提供数据完整性。
Team X can implement their own functionality and make sql view with the same name as original table for read only operations (reporting). But they can change all stored procedures for adding and removing items to/from the group. And also for obtaining items in particular group.
In such way back compatibility will be provided. Any call to stored procedure will cause changes in sql view. Also this view will be locked every time when locked original table.
At the same time they will provide data integrity.
速度？
Y 团队将如何搜索属于组“3”成员的实体？我认为他们应该使用两侧带有通配符的 LIKE 运算符 - 例如
LIKE '%,3,%'- 如果包含实体的表有数万或数十万条记录或更多，它会影响性能。The speed?
How would the team Y search entities that are members of group "3"? I think they should use LIKE operator with wildcards on both sides - e.g.
LIKE '%,3,%'- and it can affect the performance, if the table with Entities has tens or hundreds thousands records or more.