Ох жесть какая... Когда дизайнят модель в RDBMS, ее дизайнят в том числе таким образом, чтобы в каких-то местах избегать конкуренции, а в каких-то наоборот - порождать. Когда же ваша структура БД имеет вид (ну там, очевидно, PK не хватает):



в ней конкуренция есть всегда , я буквально на прошлой неделе смотрел подобное решение, сказать "мне не понравилось" - это совсем ничего не сказать, там у ребят помимо того, что одна транзакция тупо перетирала данные другой (представьте что вот на этом форуме мы решили всю тему хранить в XML/JSON - теперь при добавлении нового сообщения нам придется блокировать всю строку, чтобы сообщения не перетирались, что в свою очередь будет вести к увеличению нагрузки на БД, а по "классике" такого даже не будет), решение еще пестрило другими детскими болезнями, типа вычисления следующего идентификатора как max(id)+1. Если вам кажется, что вы изобрели серебряную пулю, вам в первую очередь стоит задуматься, действительно ли она такая серебряная и почему все поголовно ее уже не используют. Что касается презентации, что вы привели, ну это реально дичь: автор явно путает две разные задачи - "как хранить" и "как быстро выбирать": я бы вот ни при каких условиях не стал бы хранить тэги (несущественные данные) в той же таблице где и часто-меняющиеся бизнес-данные (существенные), просто потому, что в обратном случае добавление тэга будет порождать конкуренцию, которая мне нафиг не нужна на ровном месте (отсылка к SO здесь неуместна - там монопольный доступ к редактированию темы), докладчик же по факту сделал откровенную дичь, не понимая, что "как хранить" и "как быстро выбирать" - это совершенно две несвязные задачи.

Прекрасно будет работать до тех пор, пока кто-то не протеряет данные и не вломит бракоделам неиллюзорных п#здюлей