.NET Dataset design

Question

У меня есть некоторые опасения по поводу разработки наборов данных.

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

Q. это хороший подход, чтобы иметь набор данных для каждой таблицы (я бы в конечном итоге имел 30-40 наборов данных для каждой таблицы БД, используя хранимую процедуру)?

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

Q. Делает ли этот подход всю систему медленнее? Если у меня будет набор наборов данных в качестве отдельного проекта, это будет полезно, так как будет легче внести изменения (мне нужно внести изменения только в одном месте)

Answer 1

Производительность с несколькими наборами данных (и несколькими запросами) обычно медленнее. Однако, что касается обслуживания, наличие одного запроса и набора данных на таблицы определенно проще поддерживать.

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

Answer 2

Я считаю, что лучший подход - иметь один набор данных на сценарий.Большим недостатком является то, что определение вашей таблицы распределено по нескольким наборам данных (если на одну таблицу ссылаются более чем в одном сценарии), что явно плохо для обслуживания, если схема изменяется;однако есть и плюсы в том, что, как бы ни были запутаны изменения, которые вам необходимо внести в свои данные на клиенте, набор данных может выполнить всю работу за вас, отслеживая изменения в отношениях / удалении дочерних элементов / вставке дочерних элементов, как бы много уровней иерархии вы ни имелии это делает обслуживание вашего приложения по мере изменения пользовательского интерфейса.

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