2-3) Не судите об архитектуре только по примеру. Зачем делать то же самое поле в новой таблице, если оно уже есть в базовой таблице?

В общем спорить нет ни времени, ни желания, вам наверно виднее, т.к. толком не работал ни с PHP ни с MySQL.

1. >>Не проще ли создать таблицу, в которой будут присутствовать только новые, специфичные именно для новости поля (news_text, news_type)? Проще!

Не проще, т.к. это скажется на производительности, потому, что чтобы получить дату или имя новости каждый раз при запросе в базу придется связывать базовую таблицу и таблицу новостей. Также неудобно это при дебаге, когда нужно будет заглянуть в БД через phpmyadmin, посмотрев на новости и найти допустим нужную по заголовку.

2. >>News связываем с Thing отношением один-к-одному. Все!

Верность данного подхода на счет связывания 1 к 1 - очень спорная штука. Одни используют такую связь, другие нет. Но хочу заметить, что согласно упрощению моделей БД, выдвинутыми Коддом отношения 1 к 1 нужно упрощать, соединяя две таблицы в одну.

3. Для всех классов потомков вы все-равно создаете таблицы, так зачем вообще нужен гемморой связей с предками, если ни прироста производительности ни скорости разработки данный подход не дает?

Можно немножко поумничаю, так сказать, сос своей колокольни?

Сама идея довольно проста: мы оперируем 3 базовыми понятиями некая сущность (класс, таблица БД), атрибут данной сущности (поле класса, поле таблицы БД) и отношение 2х сущностей по какому либо атрибуту.

Далее буду оперировать понятиями класс, поле, отношение. Есть некий класс Thing, ему соответствует таблица в БД thing. У этого класса есть 3 поля: ThingId (thing_id), ThingName (thing_name), ThingCreationDate (thing_creation_date). Это базовый класс всей модели.

Далее, допустим, мы хотим добавить понятие “новость”. Для этого нужно ввести еще один класс News. Для новости так же важно знать когда ее создали, ее название, а так же, предположим еще 2 специфических свойства - текст данной новости, и тип новости. Так зачем же нам создавать еще одну таблицу, в которой будут присутствовать некоторые поля, которые уже есть в базовой thing (thing_name, thing_creation_date)? Не проще ли создать таблицу, в которой будут присутствовать только новые, специфичные именно для новости поля (news_text, news_type)? Проще!

Поэтому мы просто наследуемся от thing и создаем новый класс(таблицу БД) news со следующими полями: news_id, news_text, news_type. News связываем с Thing отношением один-к-одному. Все!

Это конечно все клево, но вот только как создавать теперь экземпляр новости, как его удалять и как модифицировать? Для этого мы сгенерируем набор простых хранимых процедур-мапперов:

insert_news(news_id, news_name, news_creation_date, news_text, news_type)
update_news(news_id, news_name, news_creation_date, news_text, news_type)
delete_news(news_id, news_name, news_creation_date, news_text, news_type)

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

Далее… Мы смотрим на поле news_type и подсознательно чувствуем, что чем-то оно нам не нравится… Правильно! Тип-то может иметь несколько значений, причем эти значения более менее постоянные, хотя их набор может быть расширен. В контексте нашей модели, мы создаем новый класс на одном уровне с Thing и обзываем его BaseDir (base_dir в БД соответственно) с полями BaseDirId (base_dir_id) и BaseDirName (base_dir_name). От него наследуем NewsType, с одним единственным полем NewsTypeId (news_type_id). Соответственно генерируем мапперы

insert_news_type(news_type_id, news_type_name)
update_news_type(news_type_id, news_type_name)
delete_news_type(news_type_id, news_type_name)

ну а в классе news переименовываем поле NewsType в NewsTypeId (news_type - news_type_id) и добавляем отношение с классом news_type типа много-к-одному по полю news_type_id.

Ну а далее полет фантазий безграничен! Во первых, нужно добавить поле thing_internal_type_id в thing. Это поле должно ссылаться на описание типа класса (т.е. атомарный экземпляр модели). Управление видимостью полей (также как и их наличием в процедурах-мапперах) можно реализовать на основе use case. Далее можно реализовать перекрытие полей для задания им в потомках определенных характеристик и т.д. Реализовать различные системы отображения, редактирования экземпляров наших классов на основании модели этих самих классов.

По сути, больше ничего не нужно, так как это дает такую гибкость… и кстати, производительность. А главное при условии успешной реализации самой концепции, для создания любой конфигурации не требуется знание программирования и БД, т.е. работать с такой системой смогут любые категории пользователей.

ИМХО: вам лучше пойти не в сторону гибкости, а в сторону простоты. Или делать 2 интерфейса - прогера и админа. В общем удачи вам в ваших начинаниях.