Непростой вопрос новичка по динамической БД

[841kks]

Всем привет, я новичок в Yii, есть задача которую хотелось бы максимально решить средствами фреймворка.
Задача следующая:
Нужно реализовать админку, в которой администратор может создавать таблицы-справочники. Т.е. админ создает таблицу (прописывает ее название (например, tbl_new) и описание), и дальше сам добавляет в нее поля (которые в таблицу являются столбцами). При добавлении нового поля, админ устанавливает тип этого поля (например: текст, дата, флаг и т.д.), название (например, data) и описание. В любой момент времени админ может модифицировать таблицу (т.е. удалить поле, или добавить еще одно поле).
И есть пользовательская часть, в которой пользователь выбирает справочник (например, созданную таблицу tbl_new) и видит таблицу (Grid), в которой можно осуществлять поиск, добавлять новые строки в таблицу (т.е. стандартный набор действий).

Как я это вижу, структура таблиц, описывается не в самой БД а например, в XML файле.
Проблема в том что пользовательская часть не знает какие есть таблицы и поля (они могут постоянно меняться), она все это будет брать из XML файла. Смотрит какие есть таблицы - формирует меню с выбором доступных справочников, дальше смотрит какие поля есть в таблице и формирует грид. А форма для добавления/изменения новой записи в справочник тоже лезет в XML и в зависимости от типов полей (текст, дата, флаг и т.д.) указанных при создании таблицы формирует необходимые элементы управления для полей.

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

Подскажите, как лучше все это реализовать?
Всем откликнувшимся большое спасибо.

[841kks]

И правильно я понимаю что Active Record лучше использовать, когда у меня поля в таблице БД фиксированы?
Т.е. для моего случая, когда таблицы в БД генерируются во время работы приложения (т.е. изначально структура-схема БД не фиксированная), лучше использовать DAO?

[TM123]

Этот фрейморк для таких финтов не подходит, впрочем как и практически любой другой.

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

[BuCeFaL]

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

[841kks]

Этот фрейморк для таких финтов не подходит, впрочем как и практически любой другой.

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

Спасибо И обрадовали и расстроили одновременно .
Фреймворком захотел пользоваться, так как раньше делал небольшую систему (схема бд там была прописана и не менялась) и все делал ручками, т.е. можно сказать на голом php + javascript без всякого фреймворка. Плюс в том, что с одной стороны так геморойнее (многие тонкости приходится изучать), а с другой стороны интереснее так как многие детали изучаешь, и увеличивается багаж нужных знаний. Потом решил поизучать, какие фреймворки есть и наткнулся на Yii. Прелесть любого фреймворка в том что некоторые рутинные вещи делаются легко, просто а главное быстро, к примеру, аутентификация и подобные вещи.

Но ничто же мне не мешает использовать фреймворк (в той степени в которой это возможно и нужно для моей задачи) и в нем использовать например DAO для работы с БД, унаследоваться от базового класса и дальше все ручками сделать под себя. Понятно, что получается что вроде как фреймоврк используется а с другой, многое придется делать ручками а не базовыми вещами.

Кто что еще посоветует, так как хочется взвесить все за и против, чтобы понять как лучше реализовать задачу, так как задача стоит и все равно ее надо решать

[841kks]

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

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

и явный профтык в проектировании

Подскажите как тогда правильно спроектировать, при том условии что стоит подобная задача? Буду очень признателен за помощь.

[BuCeFaL]

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

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

и явный профтык в проектировании

Подскажите как тогда правильно спроектировать, при том условии что стоит подобная задача? Буду очень признателен за помощь.

Приложение может менять структуру базы только если это задача этого приложение (phpMyAdmin и тд..).
Нормальные формы придумали давным давно.
3 таблицы для хранения таблиц
1) Набор всевозможных полей с типами и прочими полями.
2) Группа полей
3) join с many to many между полями и группами.

Для хранения данных :
group_id* | field_id *| data

[841kks]

Приложение может менять структуру базы только если это задача этого приложение (phpMyAdmin и тд..).

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

Нормальные формы придумали давным давно.
3 таблицы для хранения таблиц
1) Набор всевозможных полей с типами и прочими полями.
2) Группа полей
3) join с many to many между полями и группами.

Для хранения данных :
group_id* | field_id *| data

А можно немного подробнее если не сложно, не совсем понятно.

[BuCeFaL]

tmp.png (12.45 КБ) 3770 просмотров

[TM123]

Ну почему же, я например делал такое приложение.

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

В системе программисты привлекались только для разработки системообразующих вещей или очень сложных форм и отчетов, в которых могло иметь значение, например, в каком порядке join делать. Это было не только быстрее, но и дешевле, потому что на большую часть задач не тратилось сначала время бизнес-технолога на постановку задачи, а потом программера на реализацию.

Правда делалось это не на Yii, сначала на чистом ASP.JScript, потом стали перелезать на чистый PHP, а потом я оттуда отвалил.

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

[841kks]

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

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

[841kks]

Всем кто участвовал в обсуждении большое спасибо.
Вчера долго думал с коллегами и пришли к такому решению.
Структура БД будет все-таки фиксирована, единственно в админке системы можно будет к примеру скрыть ненужные поля, и еще ряд небольших настроек, но добавление новых полей к БД и тому подобное будет невозможно.

[BuCeFaL]

Всем кто участвовал в обсуждении большое спасибо.
Вчера долго думал с коллегами и пришли к такому решению.
Структура БД будет все-таки фиксирована, единственно в админке системы можно будет к примеру скрыть ненужные поля, и еще ряд небольших настроек, но добавление новых полей к БД и тому подобное будет невозможно.

Отличное решение !
Появляется возможность создавать поля бизнес логики, к примеру поле "календарь" или другое поле которое привязано к биз. логике, показывать / скрывать в зависимости от каких то прав доступа пользователей. Так же удобство использование ORM и кэширование SQL запросов, схемы или просто данных.
Так же если добавить к полям строки (created updated num) можно определить каким по счету будет поле, дату его создания и редактирования, чего нельзя сделать со сменой схемы.

[841kks]

Отличное решение !
Появляется возможность создавать поля бизнес логики, к примеру поле "календарь" или другое поле которое привязано к биз. логике, показывать / скрывать в зависимости от каких то прав доступа пользователей. Так же удобство использование ORM и кэширование SQL запросов, схемы или просто данных.
Так же если добавить к полям строки (created updated num) можно определить каким по счету будет поле, дату его создания и редактирования, чего нельзя сделать со сменой схемы.

BuCeFaL
Вам персональное спасибо .

Действительно так будет удобнее.
А помимо всех полей в каждой таблицы планирую сделать следующие поля: user_created, data_created, last_modified_user, last_modified_data, т.е. чтобы можно было понять кто создал запись и когда, а также кто последний ее модифицировал и когда, иногда эта информация очень важна.

[mitaichik]

Начал делать что-то подобное ))

viewtopic.php?t=3320&p=20180#p20180

Там скриншоты той части, которой сделал.

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

Все "конфиги" (списки полей, их заголовки, правила валидации и пр.) храню в файле в массиве (ИМХО нахрен нужен XML когда есть var_export)

Для работы с БД (создание таблиц, добавление полей и пр.) удобно использовать CDBShema и CDBCommand - там все уже есть.

Генерирование форм - ваще не вопрос: CForm + foreach по полям. Так же у меня есть тип поля "Заголовок" - для него не создается поле в БД, но в формах редактирования он служит для логического разделения полей на группы.

P/S Возможно скажу глупость, но: вроде где-то читал что в последних версиях PHP есть (или будет?) что-то похожее на замыкание переменных, как в JavaScript. Тогда большая часть проблем с ActiveRecord должна отпасть. Надо подробнее поискать....