Why grouping entities as "1,3,41" in entity field (!!!) is worse than GROUP table and foreign keys?

Question

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...)

Answer 1

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.

Answer 2

That team may use dynamic sql for search. They just form statement

SET @query = "SELECT ... WHERE q IN (" + v + ")"; 
EXECUTE @query;

This code will work fast enough, but support of that structure and keep data in actual state is another question.

Answer 3

Two words: referential integrity.

Answer 4

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.