Разное

>а какой требуется уровень автономности этих модулей?

Не очень понимаю, что конкретно имеется ввиду. Если речь о том, насколько они независимы друг от друга, то скорее полностью. Другое дело, что в каждый момент известно, с каким модулем работает юзер в текущий момент.

# # Table structure for table content_types # DROP TABLE IF EXISTS `content_types`; CREATE TABLE `content_types` (   `Id` int(11) NOT NULL auto_increment,   `name` varchar(20) NOT NULL,   `ext` varchar(11) default NULL,   PRIMARY KEY  (`Id`) ) ; # # Dumping data for table content_types # INSERT INTO `content_types` VALUES (1,'Image/jpeg','jpg'); INSERT INTO `content_types` VALUES (2,'Image/jpeg','jpeg'); INSERT INTO `content_types` VALUES (3,'Image/gif','gif'); INSERT INTO `content_types` VALUES (4,'application/ms-word','doc');

# # Table structure for table modules # DROP TABLE IF EXISTS `modules`; CREATE TABLE `modules` (   `Id` int(11) NOT NULL auto_increment,   `parent` int(11) NOT NULL COMMENT 'modules.Id or 0 (root level)',   `name` varchar(40) default NULL,   `storage_path` varchar(200) default NULL,   PRIMARY KEY  (`Id`) ) ; # # Dumping data for table modules # INSERT INTO `modules` VALUES (1,0,'Buildings','builds'); INSERT INTO `modules` VALUES (2,1,'Build Majors','/majors'); INSERT INTO `modules` VALUES (3,1,'project descriptions','/projs'); INSERT INTO `modules` VALUES (4,2,'Major docies','/docies');

# # Table structure for table elements # DROP TABLE IF EXISTS `elements`; CREATE TABLE `elements` (   `Id` int(11) NOT NULL auto_increment,   `module_id` int(11) NOT NULL COMMENT 'modules.Id',   `Content_Type` int(11) default NULL COMMENT 'content_types.Id',   `name` varchar(20) default NULL,   PRIMARY KEY  (`Id`) ) ; # # Dumping data for table elements # INSERT INTO `elements` VALUES (1,1,1,'Img-1'); INSERT INTO `elements` VALUES (2,2,1,'Img-2'); INSERT INTO `elements` VALUES (3,2,1,'Img-3'); INSERT INTO `elements` VALUES (4,3,4,'Doc-1'); INSERT INTO `elements` VALUES (5,4,4,'Doc-2'); INSERT INTO `elements` VALUES (6,4,4,'Doc-3');

modules - кусочки иерархической структуры аггрегирования контента
storage_path в нем - элемент пути к соответствующему хранилищу файлов:
NULL - совпадает с родительским
начинается с / - считается относительно родительского
начинается с иного символа - считается абсолютным ( в рамках всей структуры хранилища приложения )


Итого
home/project/builds/ - фотки зданий
home/project/builds/projs/ - проектная документация зданий
home/project/builds/majors/ - фотки старших
home/project/builds/majors/docies/ - досье на них же :)

ссылки с полей реальных таблиц будут на elements.Id

а какой требуется уровень автономности этих модулей?

Может я погорячился... Сейчас ещё поверчу эту картинку...

>data definition language (операторы создания удаления изменения таблиц) не должен применяться при работе приложения.

Ну так они нигде и не применяются. В каком месте я ввел вас в заблуждение?
Если это про таб.3, то там нет ничего подобного. Смысл предельно простой, это как выбор цвета. Есть список, пользователь выбирает какие цвета он будет использовать.

data definition language (операторы создания удаления изменения таблиц) не должен применяться при работе приложения. Если это, конечно, не инструмент для администратора БД.
Равно как и пользовательские данные в имена компонент схемы БД попадать не должны. Такие трюки грубо нарушают нормальную форму.
Оставьте богу богово, кесарю - кесарево, слесарю - слесарево.
Разработчику - девелопинг. Пользователю - юзинг.

Видимо у меня критические дни, тяжело с мышлением стало.

Вот вы пишите:

INSERT INTO `modules` VALUES (1,'Module_A');

А что значит текстовая строка Module_A? Подозреваю, что я вновь неправильно описал имеющуюся ситуацию или непонимание возникает за-за разного понимания термина "модуль" и его реализации.

Рискну попробовать ещё раз.

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

1. Таблица "дома" (domID, domCaption, domImg)
Ну, тут всё ясно. Добавили дом, назвали его, загрузили фото.

2. Таблица "возможное дополнительные характеристики домов" (chID, chName, chDefault)
в эту таблицу заранее заносится список неких параметров, например:
1, Высота, 100
2, Список тараканов, 100
3, Расход воды, 100
N, Фото старшего дому, null

3. Таблица "характеристика дома" (chDomID, domId, chID, chValue)
Тут пользователь выбирает поля из таб.2 которые ему нужны для описания конкретного дома, и, соотв. заполняет их. В сущности связующая таблица со значением для полей из таб.2

В данном примере файлы можно грузить для таб.1 (поле — domImg), и для таб.3 (в сущности для любого поля, ибо их неопределенное кол-во и для чего они вообще понятно только тому, кто их создаст).

Вот собсно я о чём. И таких конструкций (модулей) несколько. Сейчас у меня бардак, и везде свои формы для загрузки, а хочется привести всё в общему знаменателю.

пример из поста 08.01/2015 14:30

# # Table structure for table dirs # DROP TABLE IF EXISTS `dirs`; CREATE TABLE `dirs` (   `Id` int(11) NOT NULL auto_increment,   `module_id` int(11) default NULL,   `mtable_id` int(11) default NULL,   `path` varchar(255) default NULL,   PRIMARY KEY  (`Id`) )  AUTO_INCREMENT=3 ; # # Dumping data for table dirs # INSERT INTO `dirs` VALUES (1,1,NULL,'storage/A'); INSERT INTO `dirs` VALUES (2,2,NULL,'storage/B');

# # Table structure for table modules # DROP TABLE IF EXISTS `modules`; CREATE TABLE `modules` (   `Id` int(11) NOT NULL auto_increment,   `name` varchar(20) NOT NULL,   PRIMARY KEY  (`Id`) )  AUTO_INCREMENT=3 ; # # Dumping data for table modules # INSERT INTO `modules` VALUES (1,'Module_A'); INSERT INTO `modules` VALUES (2,'Module_B');

# # Table structure for table mtables # DROP TABLE IF EXISTS `mtables`; CREATE TABLE `mtables` (   `Id` int(11) NOT NULL auto_increment,   `name` varchar(20) NOT NULL,   `module_id` int(11) NOT NULL,   PRIMARY KEY  (`Id`) ) AUTO_INCREMENT=5 ; # # Dumping data for table mtables # INSERT INTO `mtables` VALUES (1,'Tab_2_1',1); INSERT INTO `mtables` VALUES (2,'Tab_2_N',1); INSERT INTO `mtables` VALUES (3,'Tab_3_1',2); INSERT INTO `mtables` VALUES (4,'Tab_3_N',2);

# # Table structure for table mtfields # DROP TABLE IF EXISTS `mtfields`; CREATE TABLE `mtfields` (   `Id` int(11) NOT NULL auto_increment,   `mtable_id` int(11) NOT NULL,   `Content_Type` enum('(''jpg''','gif','png','txt','doc','xls') default NULL,   `dir_id` int(11) NOT NULL,   `name` varchar(40) default NULL,   PRIMARY KEY  (`Id`) )  AUTO_INCREMENT=7 ; # # Dumping data for table mtfields # INSERT INTO `mtfields` VALUES (1,1,'jpg',1,'Img-1.jpg'); INSERT INTO `mtfields` VALUES (2,2,'jpg',1,'Img-2.jpg'); INSERT INTO `mtfields` VALUES (3,2,'jpg',1,'Img-3.jpg'); INSERT INTO `mtfields` VALUES (4,3,'doc',2,'Doc-1.doc'); INSERT INTO `mtfields` VALUES (5,4,'doc',2,'Doc-2.doc'); INSERT INTO `mtfields` VALUES (6,4,'doc',2,'Doc-3.doc');

конечно. Давайте пример. Нарисую содержимое таблиц.

Логику связей на простом примере или просто словами можете написать, если не затруднит? Что-то я не могу переварить ваш пример.