Необходимо спроектировать БД. Самый важный вопрос это каким способом реализовать хранение характеристик к объекту. Характеристики могут быть текстовыми, числовыми и типа дата.
Есть 4 варианта:

1) значения характеристик, которые имеют одно значение храним в одной таблице, в виде полей таблицы.
Множественные значения характеристик (для одного объекта, к одной характеристике несколько значений), которые имеют тип Number, в другой. Связь 1 ко многим.

Минусы: Мы заранее не знаем, сколько этих характеристик будет. Следовательно, количество полей в таблице характеристик постоянно будет меняться.
Вторая таблица, характеристика только число.
Если система поменяется, то придется переписывать почти все.

Плюсы: быстрая выборка данных.

2) значения характеристик, которые имеют одно значение храним в одной таблице, в виде полей таблицы.
Множественные характеристики, которые имеют тип текст (на самом деле будет храниться и тип дата, и число) в другой.
Связь 1 ко многим.

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

3) от таблицы объектов, все характеристики хранить в вертикальном виде и группировать их по типу в разных полях (трех). связь один ко многим

Минусы: сложность выборки
сохранение процедурой
eav система
Плюсы: логика схемы проще.

4) разбить справочники и значения характеристик по 3 таблицы. связь один ко многим.

Минусы: при выборке необходимо делать union таблиц, который исключает использование индексов
Плюсы: универсальность

Dimitry Sibiryakov, Да, конечно, поиск будет осуществляться! В этом есть тоже загвоздка. Спасибо, что участвуете!

LSV,
Буду очень признательна, если вы скинете мне ссылку!

SERG1257, а поиск по характеристикам будет быстрый? Записей в таблице будет около миллиона.

SERG1257,

Oracle
пока что характеристик около 300 (можно разбить на три типа, в общем-то: число, текст и дата)
добавлять могут с выходом новых указов правительства и т.п.

Как эти характеристики будут использоваться (обновлятся, заливаться, искаться) - insert, update и select. основные операции значений характеристик к объекту.

Каков процент пустых (незаполненных характеристик)? около 30%, думаю.

По поводу традиционной. Я предложила руководству разбить значения характеристик на 3 таблицы (по типам). Эти таблицы имеют одинаковую структуру. Поэтому поиск по разным типам характеристик можно проводить при помощи union. НО! Боятся, что поиск будет долгий, индексы не будут использованы.

Другой вариант предлагает у нас программист: создать в таблице 999 полей. И по мере добавления новой характеристики заносить 300+i значение. Но мне кажется, что это тоже не то, что надо.

Может быть XML лучше подойдет даже. Но здесь у меня пробел в знаниях...

SERG1257Miruk Записей в таблице будет около миллиона.Немного

Miruk поиск по характеристикам будет быстрый?Смотря какой поиск.
Тупо seek по одному индексированному полю - однозначно быстрый.
Index scan уже помедленне.
Table scan - перечитает всю таблицу (но только одну).
А Table scan для EAV перечитает все таблицы.

Я про поиск значений характеристик, используя XML.

babona, статья там мне тоже не дала однозначного ответа
а вот статья http://habrahabr.ru/post/247767/ заставила призадуматься

SERG1257Miruk пока что характеристик около 300Немного
Miruk добавлять могут с выходом новых указов правительства и т.п.
То есть не внезапно, по желанию левой пятки. Вышел указ - разработана новая версия приложения - добавлен скрипт на базу.
в общем-то не внезапно. но времени особо не будет. нужно будет срочно дорабатывать проект.
Miruk Как эти характеристики будут использоваться (обновлятся, заливаться, искаться) - insert, update и select. основные операции значений характеристик к объекту.
Это то понятно по-другому не получится. Вопрос будут ли они обновлятся по отдельности, по одному объекту, или скопом.
если и будут изменяться, то точно по одному объекту
Насколько критично время на обновление. Как правило чем легче писать - тем сложнее читать и наоборот.
время критично, наверное, для любого пользователя пк...
Miruk создать в таблице 999 полей.Почему не 300?
чтобы не мапить отдельно поля. Но. какого типа создавать поля от 300-999? Ну и ладно, может быть и 300 пока сошло бы на первой. А дальше??? Для меня это вариант вообще никак не нравится...
Miruk И по мере добавления новой характеристики заносить 300+i значение.А это откуда? Возможно потребуется внести дефолтное значение новой характеристики во все объекты. Объектов как я понимаю около миллиона?
А вот про дефолтное значение, если можно, поподробнее...
Miruk Я про поиск значений характеристик, используя XML. Да почти точно так же - индекс на XML по сути парсит документ, выдирает значения полей и строит по ним нормальный индекс. Все затраты - при обновлении и добавлении XML. Прелесть в том, что ничего вручную делать не надо - все заботы берет на себя СУБД.
про это обязательно почитаю! но времени в обрез, 2 программера (JS и Frontend) сидят и ждут....начальство торопит... я сойду с ума ((((

А вот про XML.
http://khpi-iip.mipk.kharkiv.edu/library/extent/dbms/viper/vip2.html
Четыре параметра важных для нашего проекта
Производительность поиска XML Плохая
Производительность выборки части документа Плохая
Производительность вставки Наилучшая
Производительность обновления (уровень под-документа) Плохая

У меня все упирается в EAV все-же... минусов у этой системы много... но и плюсы есть. что делать???

Объект - жилой дом
Характеристики: материал стен (м.б. несколько наименований)
год постройки
год кап ремонта
количество этажей
площадь
и таких характеристик пока что 300
они добавится

а вот идея разбить справочники и значения характеристик по 3 таблицы. связь один ко многим. это совсем плохая идея?


Сам бог велел делать тупо и просто.
Само просто здесь будет что???
есть 5 вариантов уже. у меня было раньше 4, здесь вариант с xml появился.
xml подойдет для большой системы с количеством пользователей около 3000 чел. с одновременной работой в системе 800 пользователей?