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

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

См. эту статью: http://www.simple-talk.com/opinion/opinion-pieces/bad-carma/

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

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

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

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

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

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

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

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

--************************************************************************
-- 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-код перебирал поля по порядку для первой страницы и помещал их на "форму мастера"... а кнопка "next" представляла поля второй страницы по порядку и т.д.

У меня были функции 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 пользовательских полей :-)