[ Вопрос ] Интеграция готовой БД с CMS

Имеется довольно большая БД MySQL (100 таблиц). Полностью готовая. Необходимо разработать сайт на основе этой БД.
Вопрос такой: целесообразно ли в данной ситуации использовать CMS ?

Дело в том, что хочу заказать разработку сайта одной из компаний. Они говорят, что будут использовать CMS. При этом связь CMS с моей БД будут устанавливать скриптами (или ещё как - не уточнял). В этой компании говорят, что быстрее и дешевле будет использовать CMS, нежели с нуля разрабатывать Систему управления сайтом.

С CMS никогда не работал. Посему не знаю, как к ним "прикручиваются" сторонние базы данных.
Насколько я понимаю, в процессе визуального "конструирования" сайта с помощью CMS последняя автоматически создаёт свои ("внутренние") таблицы необходимой струткуры. В итоге на сервере будут существовать 2 БД:
1. Основная (исходная)
2. Та, что создаётся CMS и является составной частью CMS

Вроде как такого не должно быть. БД должна быть одна. Дублироваться данные не должны.
Действительно ли проще использовать CMS + организовать синхронизацию баз, либо правильнее будет отказаться от CMS ?

Т.е. какой из вариантов является:
а) правильным (корректным с точки зрения принципов проектирования) ?
б) более простым в осуществлении (т.е. более быстрым и более дешёвым) ?

И такой вопрос: каким образом к CMS прикручивается сторонняя база данных ? Как это обычно делают ?

Хм, какая цмс? В прицепе, это мозгое..
цмс должна работать только со своей базой данных! Доп скрипты - это только непонятная доп нагрузка... Которая ни фига не оптимизированная и выглядит как костыль на костыле...
зависит от вашего бюджета и планов на будущее...
Если вам нужен эконом вариант, то можете рискнуть, и заплатить за кусочек фекалий.
Почему именно за такой лакомый кусочек? Потому что цмс - это система управления сайтом, у нее есть стандартный функционал. Расширение функционала грозит работоспособности сайту, серверу и вашим нервам. А учитывая что у вас 100 таблиц, какая тут может быть речь об оптимизации и простоте решения?

Под свою базу данных надо писать свою цмс, но это не одна копеечка, да и еще жирный минус - если что-то придется доделывать, то вы привязаны к разработчикам.

Вот она, палка в двух концах.
вы совершенно правы.
а) только разработка своей цмс
б) это как выбирать машину, либо купить дорогую и окупиться на бензине, либо старую пятерку с новыми дисками и спойлерами.

А с торговыми/бухгалтерскими программами работали? Ну представьте, что у вас 1С. И приходит к вам человек и говорит, что надо "прикрутить" некую стороннюю базу (произвольного формата) к ней..
Ну, например, так работают интернет-магазины. http://www.webasyst.ru/support/help/...tegration.html
Вообще все зависит от того, что именно у вас на сайте и что в базе и насколько часто это необходимо синхронизировать. И каков объем передаваемых данных.
Можно и не прикручивать именно базу. Можно и работать в рамках одной базы с разными таблицами. Для примера: форум phpBB запросто может использовать ту же базу, что и Joomla. База одна, префикс таблиц - разный. В настройках форума и CMS указано, какой префикс у их таблиц, а там они сами разбираются.

Чет ночью вообще не соображал, умка прав от части, зависит от того что вы имеете и что хотите
В общем скажите что за цмс предлагают и что у вас за таблицы (товары, база фсб)

Предполагаемые CMS: Joomla, Drupal.

C разработчиками проблем нет и не будет. Здесь всё схвачено.
Что касается сайта, то он имеет очень широкую направленность. Т.е. содержит в себе (реализует) почти весь функционал, предоставляемый соверменными CMS (рассматриваю Joomla, Drupal). Это и пользователи, и сессии, и рекламные баннеры, и новости, и статьи, и всякие готовые средства оптимизации, администрирования и настройки сайта. Посему и встаёт вопрос выбора в качестве основы некоторой универсальной CMS. Если CMS не использовать, то реализация всего этого функционала будет слишком затратной и с точки зрения времени, и с позиции материальных затрат (даже при использовании каких-либо фреймворков). Ведь современные CMS разрабатывались не один год и не одним разработчиком. И самостоятельная реализация функционала сайта равносильна разработке собственной универсальной CMS (пусть и не в полном объёме, но как минимум, на 50%).

Дело в том, что данные, содержащиеся в моей БД (та, что содержит 100 таблиц), на сайте только отображаются (плюс некоторые фрагменты результрующего текста оформляются в виде ссылок и имеют всплывающие подсказки). Joomla и Drupal ведь позволяют разрабатывать собственные модули. Вот через такие модули можно обращаться к своей базе данных и формировать результирующий HTML-фрагмент для отображения на сайте.
Т.е. собственные скрипты, фактически, будут извлекать из моей БД информацию и приводить её к виду, в котором она должна отображаться на сайте. И всё. Ввод данных в мою БД через сайт осуществляться не будет. Благодяря чему, интерфейс взаимодействия этих скриптов (модулей) с CMS можно сделать очень тонким и тем самым свести зависимость этих скриптов (модулей) от CMS к минимуму.

Ну это то же самое, что и работать с БД CMS.
Вообще, возможны 2 варианта:
1. С помощью CMS (средствами "визуального конструирования" сайта) создать структуры данных, аналогичные тем, что содержаться в моей БД. И далее по мере необходимости синхронизировать базы. В этом случае на сервере будут 2 базы данных, содежращие одни и те же данные: моя БД и БД CMS. К тому же идёт сильная привязка в версии CMS (в разных версиях CMS структура БД может меняться).
2. С моей БД работа идёт только через собственные модули CMS. В этом случае дублирования данных не будет.

Первый вариант принципиально нереализуем, поскольку модель данных, которые содержит моя БД, невозможно воспроизвести с помощью современных CMS (средствами "визуального конструирования") в силу высокого уровня абстракции CMS и сложности предметной области. Т.е. данные, хранящиеся в моей БД, со всеми её связями невозможно уложить в логику базы данных CMS так, чтобы с этими данными можно было работать в режиме визуального конструирования.

-----
Пока рассматриваю такой вариант: в качестве основы используется CMS с её собственной базой данный. Часть функционала сайта будет реализована с помощью стандартных средств CMS, часть - реализована с помощью собственных модулей. Собственные модули (в основном, только отображение информации) работают только с собственной БД.

Какие ещё минусы имеет вариант использования [CMS + собственные модули, работающие с собственной БД], кроме необходимости наличия в штате программистов и более высокой нагрузки на сервер ?

при условии: что ни пользователь, ни вы, не будете работать с бд (она будет только выводиться), тогда на самом деле проще использовать цмс, если ее функционал вас удовлетворяет.

По опыту скажу, джумла прилично прожорливая цмс, особенно по отношению к базе данных (с друпалом не работал). Поэтому если по мимо основной нагрузки джумлы добавить еще и скрипты для 100 таблиц... В общем если бд останется живой, то будет очень долго тянуть запросы.

P.s. А да, джумла еще и самая косячная по отношению добавления скриптов в нее, ой сколько у меня гемора было из-за джумлы))

С этой штукенцией знакомы? http://wedal.ru/rasshireniya-joomla/...a-dannykh.html

..причем это не единственный конструктор данных под джумлу, есть и другие. Вообще вы какие-то конструкторы данных под ту же джумлу смотрели-ковыряли и ни один не подошел?

Отсюда и предложение работать именно в рамка одной базы, а не двух.
Нет, не "тоже самое" - связывать таблицы в одной БД проще и удобнее, чем в разных.

Напишите хоть десяток названий таблиц. Что за база такая?
Я за yii framework ну или просто фреемворк. не представляю работу это чудо джумла и левая база.

Коммерческая тайна ))

Насколько я знаю, и Joomla, и Drupal предоставляют средства для подключения к внешним базам данных.

----------------------------------------------------------------------------
Сайт планируем разместить на выделенном сервере. Т.к. посещаемость в перспективе будет приличной. Да и SQL-запросы (некоторые) весьма непростые.

Что значит, "останется живой" ?

-----
Так это, как я понял, надстройка над РБД ядра CMS, позволяющая в БД ядра CMS хранить и обрабатывать дополнительные данные, о которых CMS не знает. Опять-таки сильная зависимость от CMS и этого самого конструктора. Предпочитаю напрямую работать с РБД. Это ж всё своё... родное...

==============
Немного лирики.
Здесь встаёт вопрос о том, насколько данные, отображаемые на сайте, будут самодостаточны и независимы от CMS. Вообще, я не люблю "визуальное программирование" по той причине, что поведение программы тобой практически не контролируется на уровне кода. Код можно скопировать, забэкапить. А то, что ты наконструировал мышкой неизвестно где, как и в каком формате хранится и в громадной степени зависит от IDE или CMS.
Насколько я понял, при работе с CMS программирование имеет место только при разработке собственных модулей. И только через код таких модулей можно обращаться к своей собственной (т.е. внешней по отношению к CMS) базе данных. Всё, что "конструируется" визуальными средствами CMS, сохраняется в собственной БД CMS, которая хранит всё - и настройки, и пользователей, и собственно информацию, отображаемую на веб-страницах. Наприме, Joomla 2.5 при установке создаёт БД из 61 таблицы и далее в процессе визуального конструирования сайта всю информацию раскидывает по этим таблицам.
Структура такой БД вовсе нечитабельна и понимается только самой CMS / конструктором данных. Вот здесь как раз и имеет место полная зависимость БД с твоей информацией от испольуемой CMS / конструктора данных. Выдирать из её БД некоторую информацию в целях бэкапа - это какой-то изврат.

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

Всего-навсего я хочу хранить свою информацию (ресь о моей БД из 100 таблиц) в свой базе данных, которую я хорошо знаю (в частности, её структуру), которую можно забэкапить в любой момент, которую можно "прикрутить" к другой CMS, которую можно перенести в локальную систему и работать с этой базой с помощью какого-либо прикладного приложения. Данные должны быть "моими", а не CMS.

Не совсем. 61 таблица - это ядро. Каждый отдельно устанавливаемый компонент (плагин) создает свои новые таблицы в этой БД. Поставили SEF404 - он пяток таблиц добавил, поставили компонент магазина - он еще штук тридцать таблиц туда кинет. И каждый компонент свои таблицы для хранения данных и юзает.
Поставьте на чистую сборку несколько больших компонентов - увидите сами.
То что вы описываете у той же джумлы называется компонентом, за исключением того, что это одна база с разными таблицами, а не разные базы.
У каждой CMS свои особенности и своя структура. Вы хотите сделать универсальный ключ от всех дверей?

Я хочу, чтобы моя БД не зависела от CMS (эта БД содержит только специфические для моей предметной области данные и не содержит информацию о пользователях, новостях и прочих уже реализованных в CMS полезностях). Одна из причин: эта же БД (вернее, другая БД, но той же самой структуры) используетсся в другой (локальной) системе. И эти БД между собой периодически синхронизируются. На сайте информация только отображается. В локальной системе - вводится, анализируется и т.п.

В крации. Берется цмс, любая...
У нее есть уже какой-то функционал, вы этим функционалом пользуетесь. Но также на определенных страницах будут срабатывать скрипты, которые будут тянуть информацию из базы данных. И не важно какая цмс (я то сначала вообще о другом подумал )
Чтож, мы выяснили что скрипты можно записать куда хочешь и когда хочешь... Осталось только определиться с цмс.

Категорически согласен))) Что бы написать компонент работающий с сотней таблиц да это такой гемор не каждый спец по компонентам возьмется а уж если возьмется то думаю вы испугаетесь цены. Визуальный пример как сокращается выбор.

серые это все программисты php
красные умеют писать компоненты
желтые смогут справится с вашей задачей
А зеленые это те кто умеют писать компоненты и смогут справится с вашей задачей.

umka from ufa,
cpentyc,
сразу видно кто у нас тут джуммастер
в вп плагины, в джумле компоненты, но вот только написать и впилить скрипт гораздо проще быстрее и менее ресурсозатратно чем подключать как "отдельный модуль"
хотя минус есть, управлять этим скриптом нельзя будет "как хочешь", надо лесть в код.

Если ТС нужен сайт с новостями и прочей лабудой то согласен ставим вп или джумлу, но ничего не мешает добавить каталог myDb100Table и в него положить скрипт. Просто фрэимворк джумлы грузнее обычного зенда yii или коде ингайтера. А про вп вообще молчу потому что некомпетентен.