Потому что класс не может иметь двух членов с одинаковыми именами. «новый» не будет делать то, что вы хотите. «новый» скрывает унаследованный член; это не дает вам двух разных участников с одинаковым именем. Таким образом, если сгенерированный код использует «new», вы никогда не сможете получить доступ к значению «родительской таблицы» из своего кода C #. Для обеих таблиц базы данных хорошо иметь два столбца с одинаковыми именами, но вам нужно переименовать повторяющиеся имена столбцов в вашей концептуальной модели, когда две таблицы составляют один класс.
В терминах «дата изменения» и т. Д., Как правило, вам нужен только один. Если у вас есть супертип Animal и подтип Dog, Entity Framework считает обновление «animal» часть "или" собачья часть "типа будет обновлением всего экземпляра, как это делает C #.
Помните, что концептуальная модель и модель хранения - это разные вещи и играют по разным правилам. Будьте осторожны, думая в строго ОО или строго реляционных терминах, работая в вашей модели сущности. Внутри модели сущностей вы соединяете оба мира. Как я уже писал в другом месте :
Одним из ментальных барьеров, которые вы должны преодолеть при разработке хорошего объектного реляционного отображения, является склонность мыслить в первую очередь в объектно-ориентированных терминах или реляционных терминах, в зависимости от того, что подходит вашей личности. Однако хорошее реляционное отображение объектов включает в себя как хорошую объектную модель, так и хорошую реляционную модель. Например, допустим, у вас есть база данных с таблицей для сотрудников и связанными таблицами для сотрудников и клиентов. Один человек может иметь запись во всех трех таблицах. Теперь, с строго реляционной точки зрения, вы можете создать базу данных VIEW для сотрудников и другую для клиентов, которые содержат информацию из таблицы People. При использовании одного или другого ПРОСМОТРА вы можете временно думать об отдельном человеке как о «просто» сотруднике или «просто» клиенте, даже если вы знаете, что они оба. Таким образом, у кого-то из этого мировоззрения может возникнуть соблазн сделать OO-отображение, где Employee и Customer являются (прямыми) подклассами Person. Но это не работает с данными, которые у нас есть; поскольку у одного лица есть записи как о сотруднике, так и о клиенте (и поскольку ни один экземпляр Person не может одновременно иметь конкретный подтип Employee и Customer), отношение OO между Person и Employee должно быть составным, а не наследованием, и аналогично для Person и Customer.