Странная схема хранения данных в БД

Имхо, зависит от специфики проекта и от того, насколько часто будут менять структуру БД...

Если структура меняться не будет - нафига придумывать себе проблемы?

Мне такая схема кажется рабочей, только если заюзать persistence layer. А вообще все это смахивает на real enterpriZe a ля thedailywtf.com :)

Такой способ организации схемы даже имеет свое название (не могу сейчас его вспомнить), так что не сам он это придумал. Только, ИМХО, способ этот плох как минимум одним - типы у атрибутов разные, а их все складывают в одну колонку. Кромк того, производительность вызывает сомнения.

Вообще такое впечатление, что это было придумано до появления нормальных ORM :)

> Есть и положительные моменты: 1. Если надо добавить новый атрибут то ничего делать не надо, мы просто добавляем какие надо атрибуты и всё.

Именно для этого такой способ и применяют. Если перечень атрибутов известен заранее, то он не имеет смысла.

Пробовали, производительность окзалось просто УЖАСНОЙ. По причине того, что запросы получались слишком сложные. К тому же в такой схеме нельзя реализвать ключи к другим таблицам. Потом мы всё переделали под нормальные таблицы. Это можно использовать только в случае, когда уж очень нужна расщиряемость во время работы. Пусть товарищь, который это предложил почитает про MVC. Мне кажется, что он очередной любитель изобретений велосипедов.

Сам то я за обычную традиционную схему с использованием ORM (sqlalchemy), при этом мне не составит труда добавить к классу (таблице) новый атрибут (колонку) и для этого не придётся перелопачивать всю программу, только локально в одном месте, где описывается схема.

Единственные сомнения это за сколько времени на PostgreSQL будет происходить на живой базе на таблице из нескольких тысяч - десятков тысяч строк ALTER TABLE с добавлением столбца, и не приведёт ли это к каким либо печальным последствиям.

Если у кого есть соображения на этот счёт, поделитесь пожалуйста.

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

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

Более того, даже статичные данные (атрибуты) иногда принято в отдельную таблицу сунуть - на этом даже выйграть можно.

Ну, короче, проверил я как работает ALTER TABLE ADD COLUMN, на 40 тысячах записей. Работает практически мгновенно.

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