Как спроектировать общую базу данных, макет которой может меняться со временем?

Question

Вот хитрый вопрос - как мне программным образом создать и опросить базу данных, содержимое которой я не могу предвидеть?

Я внедряю стандартную систему ввода данных. Пользователь может создавать формы PHP с макетом WYSIWYG и использовать их для любых целей. Он также может запросить ввод.

Итак, у нас есть три этапа:

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

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

Вопросы и замечания:

А) Как лучше всего структурировать базу данных с точки зрения таблиц и столбцов? Как насчет первичных ключей? Моей первой мыслью было использование имени элемента управления для идентификации каждого столбца, затем я понял, что пользователь может редактировать форму и переименовывать, так что, возможно, «имя» становится «сотрудником» или «зарплата» становится «: зарплата». Я склоняюсь к уникальному номеру для каждого.

Б) как лучше всего набирать строки? Я думал о временной метке, чтобы я мог сделать запрос, и о столбце для идентификатора строки из A)

C) Я должен обработать переименование / вставку / удаление столбца. Для удаления, я не уверен, следует ли удалять данные из базы данных. Даже если пользователь больше не вводит его из формы, он может захотеть запросить то, что было введено ранее. Или могут быть некоторые юридические требования для сохранения данных. Любые ошибки в столбце переименовать / вставить / удалить?

D) Для запроса я могу заставить мой PHP опросить базу данных, чтобы получить имена столбцов и сгенерировать форму со списком, где каждая запись имеет имя столбца базы данных, флажок, чтобы указать, следует ли его использовать в запросе, и на основе типа столбца, некоторые критерии выбора. Этого должно быть достаточно для создания поисковых запросов, таких как "position = 'старший продавец' и зарплата> 50k".

E) Мне, вероятно, нужно сгенерировать некоторые причудливые диаграммы - графики, гистограммы, круговые диаграммы и т. Д. Для получения результатов числовых данных во времени. Мне нужно найти хороший FOSS PHP для этого.

F) Что еще я забыл?

Мне все кажется очень сложным, но я - база данных n00b - может быть, это просто для вас, гуру?

---

Редактировать: пожалуйста, не говорите мне не делать этого. У меня нет выбора: - (

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

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

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

Answer 1

"Все это кажется мне очень сложным, но я являюсь базой данных n00b - может быть, это просто для вас, гуру?"

Нет, на самом деле равно сложно.По сути, вы описываете не приложение базы данных, а приложение базы данных builder .На самом деле, это звучит так, как будто вы хотите закодировать что-то вроде Google App Engine или веб-версию MS Access.Написание такого инструмента потребует много времени и опыта.

Google реализовал гибкие схемы, используя свою платформу BigTable.Это позволяет вам согнуть схему в значительной степени по желанию.Суть в том, что эта гибкость делает очень трудным написание запросов, таких как "position = 'старший продавец' и зарплата> 50k".

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

Вещи, которые ваша схема метаданных должна хранить

Для создания схемы:

• отношения внешнего ключа (РАБОТНИК работает в ОТДЕЛЕ)
• уникальнобизнес-ключи (может быть только один ОТДЕЛ, называемый «Продажи»)
• справочные данные (допустимые значения EMPLOYEE.POSITION)
• тип данных столбца, размер и т. д.
• независимо от того,столбец необязательный (т. е. NULL или NOT NULL)
• сложные бизнес-правила (надбавки сотрудников не могут превышать 15% от их заработной платы)
• значение по умолчанию для столбцов

Длягенерация интерфейса

• отображаемые имена или метки ("Заработная плата", "Зарплата")
• виджет (раскрывающийся список, всплывающий календарь)
• скрытополя
• производные поля
• текст справки, советы
• проверка на стороне клиента (связанный JavaScript и т. д.)

Последнее указывает на потенциальноесложность в вашем предложении: обычный дизайнер форм, такой как Джо Соап, не сможетo сформулировать JS, чтобы (скажем) проверить, что входное значение находится между X и Y, поэтому вам придется выводить его с использованием шаблонных правил.

Это ни в коем случае не исчерпывающие списки, оно просто отключеномакушка моей головы.

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

последнее слово

'Моей первой мыслью было использование имени элемента управления для идентификации каждого столбца, затем я понял, что пользователь может редактировать форму и переименовывать, так что, возможно, «имя»"становится" работником "или" заработная плата "становится": зарплата ".Я склоняюсь к уникальному номеру для каждого. '

Ранее я создавал генераторы схемы базы данных.Они трудолюбивы.Одна вещь, которая может быть сложной, это отладка динамического SQL.Так что сделайте это проще для себя: используйте настоящие имена для таблиц и столбцов.Тот факт, что пользователь приложения теперь хочет видеть форму под названием HEADCOUNT, не означает, что вам нужно переименовывать таблицу EMPLOYEES.Следовательно, необходимо отделить отображаемую метку от имени объекта схемы.В противном случае вы обнаружите, что пытаетесь выяснить, почему эта сгенерированная инструкция SQL не удалась:

update table_11123
set col_55542 = 'HERRING'
where col_55569 = 'Bootle'
/

Таким образом, лежит безумие.

Answer 2

По сути, вы спрашиваете, как создать приложение без спецификаций. Реляционные базы данных не были разработаны таким образом, чтобы вы могли делать это эффективно. Распространенным подходом к этой проблеме является проект Entity-Attribute-Value, и для типа системы, в которой вы хотите его использовать, вероятность сбоя составляет почти 100%.

Например, не имеет смысла, что столбец с именем «Имя» может стать «Зарплатой». Как будет отчет, где вы хотите, чтобы общая зарплата работала, если бы значения зарплаты могли иметь «Фред», «Боб», 100К, 1000, «много»? Базы данных не были предназначены для того, чтобы кто-нибудь мог что-то положить куда-либо. Успешные схемы базы данных требуют структуры, которая означает усилия в отношении спецификаций о том, что должно храниться и почему.

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

Answer 3

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

Answer 4

См. Эту статью: http://www.simple -talk.com / мнение / мнения / bad-carma / для чьего-либо опыта вашей проблемы.

Answer 5

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

Answer 6

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

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

--************************************************************************
-- Create the User_forms table
--************************************************************************
create table User_forms
    (
    form_id            integer identity,
    name               varchar(200),
    status             varchar(1),
    author             varchar(50),
    last_modifiedby    varchar(50),
    create_date        datetime,
    modified_date      datetime
    )

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

-

-************************************************************************
-- Create the field configuration table to hold the entry field configuration
--************************************************************************
create table field_configuration
    (
    field_id                integer identity,
    form_id                 SMALLINT,
    status                  varchar(1),
    fieldgroup              varchar(20),
    fieldpage               integer,
    fieldseq                integer,
    fieldname               varchar(40),
    fieldwidth              integer,
    description             varchar(50),
    minlength               integer,
    maxlength               integer,
    maxval                  varchar(13),
    minval                  varchar(13),
    valid_varchars             varchar(20),
    empty_ok                varchar(1),
    all_caps                varchar(1),
    value_list              varchar(200),
    ddl_queryfile           varchar(100),
    allownewentry           varchar(1),
    query_params            varchar(50),
    value_default           varchar(20)
    );

Тогда мой Perl-код будет циклически проходить по полям по порядку для страницы 1 и помещать их в «форму мастера» ... а кнопка «Далее» отображает поля страницы 2 по порядку и т. Д.

У меня были функции javascript для обеспечения ограничений, указанных также для каждого поля ...

Затем таблица для хранения значений, введенных пользователями:

--************************************************************************
-- Field to contain the values
--************************************************************************
create table form_field_values
    (
    session_Id        integer identity,
    form_id           integer,
    field_id          integer,
    value             varchar(MAX)
    );

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

Answer 7

Не уверен насчет базы данных, но для диаграмм вместо использования PHP для диаграмм, я рекомендую изучить использование javascript (http://www.reynoldsftw.com/2009/02/6-jquery-chart-plugins-reviewed/). Преимущества этого в том, что часть обработки выгружается на клиентскую сторону для отображения диаграмм иони могут быть интерактивными.

Answer 8

Это для A) и B), и я не занимался этим, но подумал, что это интересная идея, которую Reddit использует, см. Эту ссылку (см. Урок 3 ):

http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html