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

Современные СУБД достаточно неплохо сжимают таблицы, большинство полей в которых пустые. Если у нас несколько типов карточек с существенно разным количеством атрибутов, можно создать по таблице для каждого типа. Создание таблицы со списком атрибутов ИМХО оправдано лишь там, где записей немного, скорость не критична и типы полей не принципиальны. Скажем, у нас это используется для ведения дополнительных атрибутов компаний в зависимости от их страны, потому что у каждой страны как правило свой набор классификаторов и атрибутов для юр. лиц.

I dont knowЗачем делать под каждый тип свою таблицу, может лучше будет сделать одну таблицу с полем ТИП?
Если в одном типе заполняются три поля, а в другом три десятка, разделение их на разные таблицы все же экономит место.

Еще надо подумать о том, сколько методов обработки данных у вас относится ко всем типам и сколько к каждому конкретному, но неприменимо к другим. Если практически все методы общие, а у вас несколько таблиц, то придется дублировать их для каждой таблицы, либо пользоваться обобщенными переменными, это может вызвать некоторые трудности. Если же у вас таблица одна, а методы наоборот, зависят от типа, придется писать кейсы, дополнительные проверки, которые можно было бы вынести на уровень таблиц, будь их несколько на каждый тип. То есть все зависит от вашей специфики предметной области.

stiОтветьте себе на вопрос, как часто будут у вас появляться новые типы карточек и их новые атрибуты. Если часто, то имеет смысл еще почитать про EAV, чтобы знать что есть и третий вариант.

EAV это фактически то, что топикстартер предложил с самого начала.

Еще один вариант пришел в голову, по типу как в SAP HR инфа о сотрудниках хранится. Там атрибуты сотрудника сгруппированы по областям - инфотипам, и каждый инфотип в своей таблице расположен. ID сотрудника во всех таблицах один. То есть можно для каждого типа карточки определить, нужно ли заполнять конкретную табличку, или нет. Для каждого инфотипа есть свои методы. Легче разграничивать доступ к разным инфотипам. Если есть необходимость добавить атрибут в инфотип, быстрее сделать редизайн таблицы, в которой меньше полей и записей.

SERG1257I dont know Скорость работы с этой базой, т.е важна скорость чтения, записи и обновленияТо есть вы не понимаете, что это противоречивые требования.
Ну, вряд ли ТС собирается строить множество могутых индексов в разрезе десятков измерений, которые тормозят запись и облегчают поиск и суммирование. Тут скорее противопоставление общей скорости работы базы ее размеру и простоте саппорта.


SERG1257Ortogon Если в одном типе заполняются три поля, а в другом три десятка, разделение их на разные таблицы все же экономит место. Нет, не экономит.
А вот тут можно поподробнее? Все никак не соберусь проверить это. Когда то давно проверял, на msSql2k, но там процентов 10-15 объема можно было выиграть. На современных серваках не пробовал, наверное действительно уже без разницы.


SERG1257sti то имеет смысл еще почитать про EAV, чтобы знать что есть и третий вариант.Ага особенно про недостатки этого убожества.
Уж очень категорично. Эта схема применяется в серьезных коммерческих продуктах, там, где она уместна. Например, там где нужна настройка атрибутов без привлечения разработчика и количество записей не превышает нескольких сотен.


SERG1257Поскольку речь вряд ли идет о гигантских объемах, дикой конкуренции или жесточайших требований ко времени отклика (то есть областях где применение финтов имеет смысл) имеет смысл рисовать простые и понятные модели, которые будет легко оптимизировать и поддерживать.
+1