Разное

Пользователь в админке работает с несколькими модулями. Каждый модуль предполагает работу с файлами, для него это выглядит так: к некоторым полям таблицы можно подцепить несколько файлов, т.е. загрузить на сервер.

Как лучше хранить файлы? Сделать единое хранилище с одной папкой на сервере, одну таблицу под хранение информации о загруженных файлах, и по одной таблице для каждого модуля, где прописаны связи между загруженными файлами и связями с полями в другой таблицe?

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

Таблица fileStorage
fileID
filename

Таблица модуля moduleA
filedID

Таблица модуля moduleA_files
id
filedID
fileID

Собсно, нужен совет. Может есть реализации попроще или правильней? Меня смущает необходимость для каждого модуля создавать отдельную таблицу файлов. Ну, и предпочтительно было бы хранить файлы каждого модуля в отдельной папке.

Что скажете, коллеги?

таблица moduleA из одного поля - это как?
В чем реляционность-то?

Что мешает сделать последнюю таблицу единой, добавив в нее поле идентификатора модуля?

>таблица moduleA из одного поля - это как?
да не, полей там куча, просто не виду смысла их перечислять тут, просто обозначил;

>Что мешает сделать последнюю таблицу единой, добавив в нее поле идентификатора модуля?
ммм, похоже я не совсем верно сформулировал вопрос.
модуль это логическое понятие, и состоять он может из нескольких таблиц. Или так: модуль может работать с несколькими таблицами, соотв. и цеплять файлы может к разным таблицам.

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

Если таблицы, поля, файлы и модули могут пересекаться - задавать нужно соотношение многие ко многим между ними. Таблицей-связкой.

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

PS

Хранение файлов в одном каталоге (одной кучей) - не самая удачная идея, особенно если их много), а файловая система сервера не поддерживает автоматическую баллансировку дерева имен.
К сожалению, extNfs (к последним относимая) еще много где применяется, а разработчики её думали неглубоко.
Так что есть смысл все же раскидывать файлы по каталогам.

Попробую сформулировать на иначе. Хотя уже и сам путаться начал.

Таблица 1. Хранилище загруженных файлов (со структурой описанной выше)

Модуль А
Таблица 2.1
поле Изображние1
Таблица 2.N
поле Изображние2
поле Изображние3

Модуль Б
Таблица 3.1
поле Документ1
Таблица 3.N
поле Документ2
поле Документ3


В таблицах модулей 2.*, 3.* есть поля, для которых пользователем загружаются файлы. СОбсно, вопрос в том, как:
а) организовать связи
б) желательно сделать так, что бы файлы грузились в разные папки.

Ну, как то так.

modules (id, name, ...) mtables(id, name, m_id, ...) dirs(id, m_id,  mt_id, path) mtfields(id, mt_id, content_type, dir_id, name)

Не сочтите за наглость, а можно расшифровать логику?

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

Ссылки в таблице каталогов на модуль и на таблицу-приложения необязательны (NULL) и задействуются тогда, когда соответствующий каталог применяется только для указанного модуля и\или таблицы.

По вашему выходит, что для каждого отдельного модуля с его прикладными таблицами, надо делать отдельную таблицу для пристегнутых документов?

по моему нужно всего 4 таблицы (четыре штуки на весь проект)

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

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

пример из поста 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');

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

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

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 (в сущности для любого поля, ибо их неопределенное кол-во и для чего они вообще понятно только тому, кто их создаст).

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

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

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

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

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

# # 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

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

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

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