По-моему, логика приложения проще будет, если хранить в посте либо сами комменты, либо ссылку на гридфс, где эти комменты хранятся в сериализованном виде. Хотя всё зависит от задачи, если поиск по комментам нужен, то тут да, если не писать свой поиск, то либо продолжение текущего документа, либо хранить комменты в «нормализованном» виде в отдельной коллекции
2dmiceman: раньше администрирование никсов было дело почти исключительно профессионалов, которые редко что делают наобум, да ещё не сохраняют копии и/или не документируют свои действия. Теперь никсы пришли на десктопы к домохозяйкам и школьникам, со всеми вытекающими и необходимость инструмента ака «точки восстановление» повысилась.
>вы ..., плохо изучив технологию, повысите возможность возникновения ошибок, а это прямой или косвенный ущерб для клиента.
Хороший аргумент для увеличения цены, я обычно просто увеличиваю время, не изменяя стоимости, снижая тем самым цену своего «трудодня», мотивируя тем увеличение сроков, что придётся «возиться». Но с вашим подходом есть риск (и довольно большой) вообще клиента потерять, особенно если в вашем сегменте рынка исполнители бегают за заказчиком, а не заказчики за исполнителем, например клиент может выбрать исполнителя, который знает все 5 нужных ему технологий на 4, а вы знаете 4 на 5, а одну на 0, да ещё просите больше времени и денег. Так что, если клиент важен, а конкурентов много, то аргумент про большую вероятностью ошибок лучше, наверное, не озвучивать и работать себе в убыток (хотя можно ли считать убытком, например, 20 часов работы и 20 часов изучения новой технологии за, условно, 500 у. е., если альтернатива 40 часов лежать на диване или работать эти 40 часов за 3 у. е. в час, как неквалифицированная рабочая силы: технологию не знаешь — неквалифицированный :) )
изолированность таблиц легко решить жёсктим (зашитым в коде) «соглашением» (согласен использовать — используй, не согласен — реализуй доступ к бд с нуля) об именовании таблиц, например префикс %cms_instance_name%_%plugin_name%_ для всех таблиц, в которые плагин пишет (то есть пишет или ядро в общие (без %plugin_name% в префиксе) таблицы, или плагин в свои — читать данные могут все плагины, например, для агрегации)