Вопрос о дизайне базы данных и представлениях - PullRequest
Новая
       22

Вопрос о дизайне базы данных и представлениях

0 голосов
/ 06 сентября 2011

Допустим, у меня есть база данных объектов недвижимости (квартиры, дома, промышленные помещения, офисы), и у каждого есть набор общих атрибутов (общих для всех конструкций, таких как адрес, цена, текст описания, координаты, доступная поверхность). внутри здания, тип материала каркаса (сталь, дерево, глина: D и т. д.) и т. д.). Должен ли я:

1) создавать таблицы квартир, домов, офисов и т. Д. И, когда я делаю запрос выбора, который включает все конструкции, использовать представление (скажем, all_constr), которое выбирает из всех таблиц на основе общих атрибутов, а затем уточнять результат, основанный на различных критериях (например, каркас сопротивления из дерева или из (бетон-сталь ИЛИ глина) и т. д.)

Я не совсем уверен, как вид работает под капотом, но я думаю, что если я сделаю что-то вроде 

     SELECT * FROM all_constr AS a  --all_constr is the view
     WHERE  a.price <50000 AND a.surface >100 ;

каждый раз, когда я запускаю вышеупомянутый запрос, таблицы конкретного построения итерируются один раз, чтобы создать виртуальную таблицу, и еще раз, чтобы выполнить фильтрацию. Это не кажется очень эффективным. С другой стороны, если представление AKA виртуальной таблицы хранится в виде реальной таблицы, то это почти то же самое, что и в случае 2) +, в случае, если я хочу увидеть детали, относящиеся к зданию, мне не повезло, потому что нет уникального идентификатор по домам, апс и тд Я думаю, что одним из решений было бы создать вид, подобный этому: 

     CREATE VIEW all_constr AS  
     SELECT x.common_att1, x.common_att2, x.tableoid, x.id
     FROM aps AS x
     UNION ALL  
     SELECT x.common_att1, x.common_att2, x.tableoid, x.id
     FROM houses AS x 
     UNION ALL  
     SELECT x.common_att1, x.common_att2, x.tableoid, x.id
     FROM ind_spaces AS x

2) создайте другую таблицу (скажем, constr) и свяжите aps, дома вот так:

http://imageshack.us/photo/my-images/31/unledkwx.png/ Преимущество в том, что нет необходимости использовать таблоиды

Итак, какое решение вы бы порекомендовали увидеть, поскольку, как я слышал и читал много раз, использование представлений является хорошей практикой?

LE: Если возможно, я бы хотел избежать использования наследования, поскольку оно слишком специфично для postgres (я не против, если это оптимальное решение)

Ответы [ 2 ]

1 голос
/ 06 сентября 2011

в PostgreSQL, представления являются сокращением для правил .

Когда планировщик запросов встречает правило / представление, он подставляет фрагмент запроса из правила в текущий запрос и продолжает оптимизировать запрос.

Это так же, как если бы вы ввелизапрос непосредственно из представления;Postgresql оптимизирует запрос, как будто его вообще не было, и сделает все возможное, что может.За использование представления не снижается производительность.

0 голосов
/ 07 сентября 2011

Объедините все общие элементы в одну таблицу и добавьте столбец типа (зарезервированное слово ...) в эту таблицу.Сделайте необязательные атрибуты обнуляемыми или поместите их в одну или несколько отдельных таблиц.

...