Должен ли я создать модель данных объекта ADO.NET для каждой таблицы или одну для всей моей базы данных?

Question

Предполагается ли использовать одну модель данных объекта ADO.NET для каждой таблицы? Или один для всей вашей базы данных, где также маршрутизируются отношения и т.д ...

Answer 1

Сделайте это для всей базы данных. Если вы создадите модель данных для каждой таблицы, вы не сможете пользоваться связями.

Если вы используете управление исходным кодом извлечения / слияния, такое как Subversion, имейте в виду, что разработчик использует XML до такой степени, что Subversion пытается слить его. В этом случае вам обычно приходится каждый раз восстанавливать всю модель или объединять вручную.

Answer 2

Я использую Entity Data Model для связанных таблиц. В зависимости от размера вашей базы данных я бы создал только одну модель, если бы было менее 20 или 25 таблиц. Создание отдельных моделей для каждой таблицы немного дороже, поскольку каждая модель имеет объект EntityConnection, который необходимо создать.

Я считаю, что могу поддерживать модели достаточно хорошо, если у меня от 5 до 15 таблиц. Мой главный решающий фактор - это функциональность. Я строю инженерные приложения, поэтому, например, у меня есть около 6 таблиц компонентов из конструкционной стали. Они все в одной модели. Они имеют общие инженерные атрибуты, поэтому проще повторно использовать код, специфичный для управления этими атрибутами.

Это означает, что я могу создавать экземпляры модели, создавать объекты, манипулировать / организовывать эти объекты в общем файле кода. Любые изменения, которые необходимо распространить обратно в базу данных, могут быть выполнены довольно эффективно.

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

Манипулирование памятью намного дешевле, чем дисковый ввод-вывод. Это просто мой взгляд на структуру, и я ни в коем случае не эксперт в этом.

Answer 3

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

Answer 4

Я разработал бы концептуальную / объектную модель данных независимо от схемы базы данных, а затем создал бы отображение, которое наилучшим образом связывает концептуальную модель со схемой базы данных. Может использовать большинство, если не все таблицы. Если вам нужно сопоставление таблиц «один-к-одному», вы можете вместо этого рассмотреть LINQ-to-SQL, поскольку с ним проще работать.

Answer 5

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

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

Answer 6

Я думаю, что если у вас большая база данных, вам нужно классифицировать таблицы базы данных. Но вы должны создать класс для каждой таблицы, который является основным требованием структуры сущности ado.net.

При обновлении базы данных, вы можете сделать с обновлением модели данных.

Сначала создайте базу данных, а затем создайте модель сущности ado.net.