Мысли в слух о ревизии 554
Посмотрел, что в ревизии 554 сделали удаление связанных данных.
Сначало подумал, а почему бы, как и ранее просто не «связать» ключи (ADD CONSTRAINT блабла FOREIGN KEY (`блабла`) REFERENCES `блабла`)
Ну не судите строго… думал я в 4 ночи почти…
И тут осенило, что эти таблицы, удаление из которых осуществляется функциями, не имеют «чётких» индексов (topic_id, comment_id), а лишь target_id… то бишь непонятно что вообще с чем связывать-то. Удаление средствами InnoDB невозможно (ну как я понимаю).
Остаётся вопрос… а как правильней с точки зрения целостности данных: разделить на две таблицы каждую из них и сделать удаление связанных данных средствами InnoDB или всё же слить (как щас) и делать удаление функциями?
Я естественно не в коем случае не призываю что-то менять и как-то действовать относительно движка, просто я человек любопытный и излагаю теорию и задаюсь теоретическим вопросом ^_^
Сначало подумал, а почему бы, как и ранее просто не «связать» ключи (ADD CONSTRAINT блабла FOREIGN KEY (`блабла`) REFERENCES `блабла`)
Ну не судите строго… думал я в 4 ночи почти…
И тут осенило, что эти таблицы, удаление из которых осуществляется функциями, не имеют «чётких» индексов (topic_id, comment_id), а лишь target_id… то бишь непонятно что вообще с чем связывать-то. Удаление средствами InnoDB невозможно (ну как я понимаю).
Остаётся вопрос… а как правильней с точки зрения целостности данных: разделить на две таблицы каждую из них и сделать удаление связанных данных средствами InnoDB или всё же слить (как щас) и делать удаление функциями?
Я естественно не в коем случае не призываю что-то менять и как-то действовать относительно движка, просто я человек любопытный и излагаю теорию и задаюсь теоретическим вопросом ^_^
4 комментария
Поэтому появилась единая таблица vote, единая таблица favourite и другие. Для их обслуживания были введены единые модели и единые сущности.
Почему дорабатывать функционал стало проще? К примеру, если вы делаете модуль «Фотографии». Вы создаете новый контент — фотка. Вам не нужно заботиться о написании функционала комментирования, так как вы можете использовать единый модуль Comment (просто добавив в базе данных новый таргет foto), вы можете не писать новую систему голосования, а использовать для этого уже готовый модуль Vote (снова-таки, просто добавив в одном поле базы данных новый target), ваши фотки можно очень легко заносить в избранное, и вам для этого не нужно создавать новый функционал — для этого можно просто использовать Fvourite-модуль.
Вот такой вот ход мыслей.
По поводу InnoDB, мы стараемся наоборот освободить пользователей от этого требования к базе данных. Так что это не последний коммит, который касается работы со связанными данными. Оставайтесь на линии :)
А ход мыслей то понятен… Что делается всё, что бы движок был как можно гибче. Это и так понятно)
2. Для остальных случае в конфигурации предусмотрена настройка. Точнее, будет предусмотрена, это давно оговорено :)