|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго времени суток!
Есть такая задача - у набора фирм есть набор клиентов, информация о которых хранится в базе. Руководитель каждой фирмы сам решает, какие поля и название этих полей хранить о своих клиентах - получается для каждой фирмы как бы своя таблица с набором полей и их типом.
Как можно реализовать динамическую структуру полей таблицы для каждой фирмы, не создавая, естественно, для каждой фирмы свою таблицу. Сортировка по всем полям естественно должна производиться, будь то дата добавления, или номер телефона. Если бы все поля были VARCHAR, тогда можно было бы создать таблицу, в которой хранились бы идентификатор фирмы, название поля и идентификатор этого поля. И в общей таблице хранить уже идентификатор поля как foreign key, идентификатор фирмы как foreign key и сами данные этого поля. Но в данном случае речь идет о разном наборе полей разного типа для разных фирм.
Придумал одно решение, но ввиду его неоптимальности и кривизны пока приводить не буду, чтобы не сбивать ход мыслей.
Неактивен
Учитывая то, что схема такая общая, можете хранить все данные в TEXT в
виде XML: всё равно все поиски будут производиться в клиентском коде.
А вообще для этих целей лучше подойдет какая-нибудь no-sql база. Напри-
мер, MongoDB.
Неактивен
Для хранения в TEXT слишком много записей для каждой фирмы, производительность немаловажна, добиться скорости работы MySQL c ее индексацией.
Мой вариант создать таблицу, в которой будут все поля возможных типов, а заполнять только один столбец нужного типа и хранить номер столбца. и как вариант сохранять в базу готовый sql запрос выборки, поиска и т.д для каждой фирмы. Таким образом, получится для каждой фирмы создать свой набор полей с разными типами, благо их всего три: VARCHAR TEXT DATETIME.
Получается, конечно, очень жесткий перерасход памяти, но все будет делаться штатными средствами, хотя при реализации могут появиться проблемы.
Спасибо, посмотрю в сторону MongoDB, единственное, что уже создана большая система на MySQL, а вышепоставленная задача реализуется как модуль, поэтому переход нежелателен.
Неактивен
Да есть техника.
Таблица с данными, заранее созданные поля : column_var_1,column_var_2,column_var_3,column_int_1,column_int_2,column_int_3 ...
Таблица с описанием таблиц
table_name,table_column,sys_table_column
'users','column_var_1','first_name'
Неактивен
Evgeny, могли бы Вы немного подробнее описать, но как я понял, что от перерасхода памяти не избавиться никак. Не хочется терять связи foreign keys. Я не уверен, но они дают прирост производительности в разы. Так ли это?
Ведь вообще, можно было бы создать три таблицы с разными типами данных, а в основной таблице тупо идентификатор на таблицу и на поле. Но сделать это foreign key не получится, таблицы то разные. Значительное ли будет снижение скорости при таком подходе? В этой задаче скорость важней, чем занимаемая память, поэтому лучше жертвовать памятью, если я правильно понял предложенный вариант.
Неактивен
Да, забыл, фирмы могут создаваться, удаляться, клиенты также. Руководитель в любой момент может поменять набор полей для своих клиентов.
Неактивен
Для каждой фирмы не много записей, а одна. В этом большая разница 
Неактивен
могли бы Вы немного подробнее описать,
В коде у вас генерируется читабельный запрос select * from users where user_id=20;
потом ваш обработчик его переводит в
select * from general_data where table_name='users' and column_int_1=20;
Если предположительно могут быть проблемы с производительностью, то упростить и делать без обработчика.
но как я понял, что от перерасхода памяти не избавиться никак.
Необязательно ... Это зависит от многих факторов.
Не хочется терять связи foreign keys. Я не уверен, но они дают прирост производительности в разы. Так ли это?
foreign keys даёт прирост производительности ? Это за счёт чего ? Не слышал про такое ... Может кто то меня поправит ... Кинет сылку ...
Значительное ли будет снижение скорости при таком подходе?
Ну это всё зависит уже от самого приложения ... От количества запросов, чтения и записи ... От количества индексов ... От кешируемости запроса.
Что за приложение вообще ?
Есть ли надобность в динамичности для всех таблиц ? Может достаточно только для части.
Неактивен
Смысл в том, что есть портал, на котором регистрируется множество фирм, что-то типа соц сети только для бизнеса, где страничка - это лицо фирмы. И в пределах системы создается CRM (см. Википедию). Каждый менеджер ведет клиентов, заводит для них карточки, заполняя соответствующие поля. Ввиду общей задачи, набор полей меняется и настраивается под конкретные нужды. То есть, название клиента, номер телефона, адрес. Другой руководитель решил, что им надо Сферу деятельности, комментарий, и что-то еще. То есть, каждый настраивает свою CRM под свои нужды. Получается у каждого как бы своя таблица, причем поля могут быть разного типа - например дата поставки, дата регистрации, комментарий и т.д. И расширенный поиск позволяет производить сортировку по всем этим полям для каждой фирмы.
Не могли бы вы расписать структуру таблиц и связи, не совсем понятно что откуда.
Мы не можем заранее создать таблицу для всех фирм - набор полей и их тип изначально не известен (известны возможные типы - датавремя, текст и строка), после включения соответствующего модуля предлагается настройка перечня полей и их типов.
Динамичность, конечно, здесь нужна только при настройке, сам набор полей будет редко дополняться в процессе работы, после того, как система будет настроена каждой фирмой. То есть кэшировать можно успешно, как запросы к базе, выборки, поскольку менеджеров у конкретной фирмы может быть много, и они постоянно добавляют-изменяют-удаляют карточки клиентов, заполняя ранее определенный набор и тип полей.
Неактивен
Получается, если foreign key нужны только для удобного каскада и апдейта, то можно обойтись и без них, таким образом создав три таблицы дат, текстов, строк, и для каждой фирмы одно поле карточки клиента будет определяться как идентификатор таблицы (одной из трех) и идентификаторов записи в этой таблице, и не важно какого оно будет типа, т.е. решение без foreign keys.
Неактивен
Я имел виду создать таблицу с липовыми полями ... То есть например таблицу с 5 полями int и с 5 varchar.
Но в вашем случае вариант
Ведь вообще, можно было бы создать три таблицы с разными типами данных, а в основной таблице тупо идентификатор на таблицу и на поле.
по моему на много лучше.
Насчёт производительности, у вас всё просто ... Статические страницы (файловый кеш) переписывающиеся в случае когда делают изменения. То есть при заходе на анкету, к базе вообще не нужно обращаться. Единственное напрягающее базу действие будет поиск. Для этого необходимо сделать индекс на все поля + таблицу с типом text в MyIsam для fulltext index. То есть всего будет типов 4 : int,varchar,datetime,text
Неактивен
