Реально можно все в одной хранить? Ухты Спасибо большое что

рассказал

таблица будет "дырявой", не нормализованной ни по одной форме...

Эмм, что?

в непересекающихся по модели колонках будет null, поэтому такое жаргонное выражение — "дырявая"

Первый раз такое слышу, ну допустим кто-то её так называет. С чего бы она не будет нормализованной?

потому, что будет избыточной

И, дальше что?

что дальше что? Ничего. Таблица не нормализована.

но данные хранить будет исправно, всё стерпит.

То, что там есть null'ы == таблица не нормализована? Что за бред?

вы в одной таблице пытаетесь сохранить описания двух разных сущностей. Это неверный подход к проектированию баз, вот и всё.

С вопроса о том, что таблица с нулами почему-то оказывается ненормализованна съехали к неправильности проектирования базы. Речь про наследование шла если что, а не про то, чтобы все возможные сущности запихнуть в одну таблицу

А почему она с нулями оказалась? Не потому ли, что в ней размещены два разных типа сущностей? Если ответ "нет" — значит, я неверно понял ситуацию, за что готов извиниться

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

Все же я, наверное, прав — сужу исключительно по описанию задачи.... речь про разные типы сущностей. "Но как я буду хранить в одной таблице разные модели? У них же есть свойства отличающиеся"

Ну отмотай повыше, что человек хочет на самом деле

Отмотал. Родительский класс Парки от которого есть 2а класса наследника, это городские парки и лесные Вижу два типа сущностей: 1. гор парки 2. Лесные

Да, они наследники парков

Но имеют разные (уникальные) свойства. В результате по этим _непересекающимся_ свойствам в таблице будет иметь _гарантированные_ нули и получим ненормализованную структуру.

Покажи в каком определении нормальных форм есть указание о том, что возможные null'ы не обеспечивают нормальную форму?

В подходе разделения каждой отдельной сущности на таблицы есть куча недостатков, например https://stackoverflow.com/questions/3579079/how-can-you-represent-inheritance-in-a-database#comment20815392_3579462 + там ещё комменты В целом это куча кульбитов и прыжков в длинну ради чего? Отсутствия null'ов и "красивой" схемы (условно красивой, потому что будет куча дублирования колонок) И да, наличие null'ов в таблице из нормальной формы её не выводит

Ключевая ошибка в формулировке вопроса: не _возможнные_ нули, а _гарантированные_ нули! Нули, заложенные на этапе некорректного проектирования базы данных.

Чел, приведи мне определение, где конкретно идет нарушение, мне не нужны твои головные мысли

Вы предлагаете хранить гарантированные нули (которые можно было не хранить), плюс добавляется необходимость хранения типа, к которому относится строка. Простой логики не достаточно чтобы осознать, что это избыточно и не верно? Вот хотя бы одно из определений, "таблица находится в первой нормальной форме, если она описывает одну сущность"

> Простой логики не достаточно чтобы осознать, что это избыточно и не верно? А простой логики не достаточно, чтобы понять, что дублировать все колонки для каждой сущности в каждую таблицу неверно? Вопрос риторический, есть разные подходы Тот, что ты предлагаешь - сложный в реализации и поддержке, а профитов у него примерно 0 Определение опять из головы, где ссылка на источник?

Какие две-то?... В полностью нормализованной БД для хранения описанной ТС структуре данных требуется три таблицы.