Организация данных в бд

Всем привет.
Никак не могу определиться с организацией базы данных. Ситуация такая: нужно записать в таблицу сложные данные, состоящие из нескольких определённых полей (id, дата, имя, и т.п.) + неопределённого количества неопределённых полей. Проблема, как вы понимаете, в неопределённых полях. Вот я и думаю, как лучше поступить... Самый простой способ, конечно, решить проблему втупую: просчитать все возможные варианты, и создать таблицу с большим количеством полей "на все случаи жизни". Второй вариант - создать одну ячейку для всех неопределённых полей, и писать их туда в формате csv. И третий вариант - я нашёл в интернете, что с помощью serialize можно отправить в таблицу готовый массив. Но там была приписка, что при большом объёме данных, этот способ очень тормознутый. А у меня как раз большой объём данных. Как я понял, это касается и второго варианта, т.к. в обоих случаях придётся создавать поле неограниченного размера, что, видимо, не есть хорошо. Собственно вопрос, что мне делать? Сразу говорю, разбить на несколько таблиц - не вариант.

0

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

0

Сообщение от ChildOfFlowers Никак не могу определиться с организацией базы данных

В свое время работал с OeBS - это крупная ERP-система от Oracle. Там можно было настраивать некоторые параметры, не привлекая программистов. Так вот, во всех таблицах, где были возможны такие записи, кроме обязательных полей были заведены по 30 полей типа varchar2.
Как я понимаю, этот подход похож на твой 1-й вариант. Остальные два - это нереляционный подход со всеми вытекающими, начиная от сложностей выборки, модификации, и кончая контролем целостности данных.

0

Сообщение от SailarmoonKS Создавать базу, не зная какие у вас будут поля не совсем верный подход

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

Сообщение от SailarmoonKS Значит вы еще и структуру проги не знаете

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

Сообщение от SailarmoonKS с третьим вариантом я не знаю как вы поступите, когда необходимо будет еще поля добавлять

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

Сообщение от SailarmoonKS либо второй либо третий вариант

Меня больше всего волнует вопрос производительности таких вариантов. Потому что данных будет действительно много.
В случае с массивом, мне ещё не понятно, в каком формате sql будет возвращать данные. И вообще, чем это отличается от csv? И можно ли будет производить поиск и сортировку по таким полям? Мне надо, чтобы было можно... в этом, собственно, вся задумка.

Добавлено через 9 минут

Сообщение от Grossmeister кроме обязательных полей были заведены по 30 полей

Да, я думал о чём-то подобном... Т.е. создать N количество полей с именами, допустим, 1, 2, ... 30. Но тут вопрос, как пользователю именовать такие поля? Создавать для каждого пользователя отдельную таблицу "№ поля - имя" - плохой вариант, будет миллион таблиц. А писать в каждой ячейке "имя - значение" - получится что-то похожее на 2 и 3 вариант...

0

ChildOfFlowers,
Я бы сделал проще. Создаем 3 таблицы:
1. Users (UserId,Name,Age....) - ну личная инфа
2. Colonki(ColonkiId,Name) -здесь храните(добавляете,удаляете) все возможные колонки для ваших пользователей
3. Table3(IdTable3,ColonkiId,UserId,ValueCo lonka) - а здесь уже храните значение определенной колонки для определенного пользователя.

0

Сообщение от ChildOfFlowers Но тут вопрос, как пользователю именовать такие поля?

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

0

Сообщение от Grossmeister Есть таблица с описанием метаданных. Когда твой пользователь заводит атрибут "Номер машины", то в метаданных прописывается пара "Номер машины" - fld1

Grossmeister, Это вы хорошо придумали

0

SailarmoonKS, Grossmeister, т.е., о чём я и говорил... если сейчас у меня на каждого пользователя по одной таблице "contacts", а будет по две. В общем то, я этого хотел избежать... но если вы говорите, что это лучший вариант...

Добавлено через 1 минуту
или я что-то не так понял?

0

Мне кажется ТС пытается сделать классификацию. А посему - подчиненная таблица со списком всех возможных параметров и их значений. Отдельно обратить внимание на разные типы (тоже несколько вариантов реализации)
Единственный минус - городить кучу case в запросе придется. Но это плата за универсальность

0

В моем случае 3 таблицы, а в случае Grossmeister, создаете 2 таблицы. В первой статичное кол-во колонок -например 50 и помечаете их как field1,2,3..., а во второй таблице держите информацию для пользователя какое именно для каждого пользователя соответствие колонки -название(Для 1-ого пользователя домашнее животное -это field1, снилс - field2... Для второго пользователя номер машины - field1, название животного -field2..) Соответственно зная эту информацию, вы составляете необходимые sql запросы на изменение полей. Пользователь решил поменять свой номер телефона и нажимает сохранить - ваша программа обращается ко второй таблице и находит в каком поле для данного пользователя содержиться номер телефона и составляет запрос на изменение именно этого поля

0

Сообщение от ChildOfFlowers если сейчас у меня на каждого пользователя по одной таблице "contacts", а будет по две.

Где я писал про две? Одна таблица, где есть обязательные поля и поля fld1..fld30. А что в этих полях - разрешаем через метаданные.
Можно вообще иметь одну таблицу contacts, где с пом. доп. поля owner можно определить, чьи это контакты. Тогда в таблице метаданных тоже будет поле owner, где показано, что для этого пользователя fld1 - это номер машины, для другого - день рождения ребенка и т.д.

0

Grossmeister, не пинайте, если туплю... просто слишком много всего приходится обдумывать. Значит, как я понял, имеется таблица "users" со списком всех пользователей, их логинами, паролями, и т.д. И в ней же есть поле, в котором прописаны для каждого пользователя имена и псевдонимы полей в его таблице "contacts". Так чтоли?...

0