Изучение схемы набора данных на основе данных во время выполнения

Question

Мы создали базу данных на SQL Server, используя два шаблона, которые мы нашли в книге ресурсов ресурсов модели данных Len Silverston. 3, один для типов и категорий: классификация и другой для иерархий, агрегирования и одноранговых отношений. По существу, она implmented следующим образом:

Классификация

[Объект] (М х М) [EntityType] (М х М) [EntityTypeType]

..., где (М х M) является отношением «многие ко многим», реализованным в базе данных по таблице классификации.

Ассоциация

Сущность и таблицы типа выше, также имеют свои собственные типизированных Rollups:

• [Entity] (М х М) [Entity]
• [EntityType] (М х М) [EntityType]
• [EntityTypeType] (М х М) [EntityTypeType]

... где каждый (M x M) является отношением «многие ко многим», реализованным в таблице Rollup с внешним ключом типа типа rollup/association.

Результирующая структура данных дает нам огромную выразительную способность с точки зрения описания как наших сущностей, так и их отношений друг с другом. Однако у нас возникают проблемы с использованием этой выразительности в наших приложениях. Основная проблема заключается в том, что, несмотря на успехи в EF 5, отношения M-2-M все еще сложны, и помимо этого мы пытаемся получить доступ к M-2-M по меньшей мере в 2 направлениях, когда мы попадаем в базу данных , Это особенно усложняется:

1. Мы подтип как [Entity], так и некоторые подтипы [Entity].
2. Все таблицы M2M - все таблицы классификации и свертывания/ассоциации - имеют полезную нагрузку, содержащую по крайней мере дату From и Thru. Накопители также содержат, по крайней мере, тип накопителя.
3. Мы не хотим загружать большие отдаленные части схемы ввода (таблицы EntityTypeType и их свертывания), чтобы интерпретировать данные во время выполнения каждый раз, когда мы обращаемся к объектам.

Technologies:

• SQL Server 2008 R2
• Entity Framework 5
• .NET 4.5
• MVC 4 (в части веб-приложения, мы также имеем некоторые консольные приложения)

Вопросы о самой модели:

• Является ли это просто невыполнимой моделью данных в .NET?
• Должны ли мы сначала свернуть нашу базу данных на более дружественные .NET-представления, которые по существу моделируют наши бизнес-объекты?

Вопросы о схеме набрав - иметь в виду, что типы являются довольно статичным:

• Если мы эшафот в [EntityType] и [EntityTypeType] таблицы, их классификации, а также их накопительные INTO C# классы? Это будет схоже с enum scaffolders, только нам нужно больше, чем имя/int, поскольку у них есть диапазон дат и полезных данных. Если да, то каковы некоторые идеи о том, как замаскировать эти файлы - как статические классы? Жестко-кодированные списки объектов?
• Следует ли нам кэшировать схему ввода при запуске (это беспокоит меня, потому что она добавляет много накладных расходов для запуска приложений консоли)?
• Любые другие идеи - строительные леса XML-файлов? и т.д. ...

Любые идеи или впечатления очень ценятся!

Answer 1

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

Если вы пытаетесь выпустить код, который динамически изменяет/настраивает при изменении схемы на SQL Server, тогда у меня будут разные ответы. =)

Это просто непригодная для использования модель данных в .NET?

Некоторые вещи вы упомянули, что выделились мне:

1. Множество М х М отношений.
2. Entity/EntityType/EntityTypeType
3. накопительные

Некоторые вопросы у меня после прочтения:

1. ли вы, ребята, выбрать основу для моделирования данных в надежде, что бы сделать все проще?
2. Вы выбрали рамки, потому что это казалось «правильным» способом?
3. Мне тяжело следить за тем, как вы моделировали данные. Что такое тип EntityTypeType?
4. Нужны ли все отношения M x M? Просто потому, что Entity A и Entity B могут находиться в M x M, если они?

Я не знаю вашего домена, но я знаю, что мне сложно списать то, что вы описали. =) По моему мнению, он уже стал несколько неработоспособным по двум причинам: 1) Вы спрашиваете об этом, б) Это непросто описать без большого количества текста.

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

Да!

По крайней мере, исходя из моего опыта, я бы сказал, что да. =)

Я думаю, что нормально создавать сущности в базе данных, которые имеют сложные отношения. Родительский/дочерний, равноправный, иерархический и т. Д. Все отлично, хорошо и нормально.

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

Также считайте, что если вы надавите на сложность связанных объектов с приложением, вы можете заплатить некоторые штрафы за производительность.

Должны ли мы подкрасить таблицы [EntityType] и [EntityTypeType], их классификации и их свертывания в классы C#?

Я бы посоветовал это сделать. Единственная причина в том, что теперь вы работаете с базой данных на прикладном уровне. Если вы хотите делать объединения/rollups/etc. вы управляете этими данными в приложении, а не с базой данных.

Я уверен, что вы уже знаете это, но вы хотите избежать возврата всего в базу данных в приложение и , затем запущенных запросов/строительных объектов.

SQL Server является удивительным при связывании объектов и сближении разных объектов. На этом слое будет очень быстро.

Я бы создал бизнес-объекты и заполнил их из SQL.

Если вам нужно подстроить EntityType/EntityTypeType, будьте осторожны, вы не столкнетесь с проблемами N + 1.

Каковы некоторые идеи о том, как создавать эти файлы - как статические классы? Жестко-кодированные списки объектов?

Варианты:

1. Используйте ОРМ для создания классов для вас. Вы уже видели некоторые из них с EF.
2. Напишите свой собственный инструмент для генерации кода, просмотрев схемы SQL Server для ваших объектов.
3. Пишите классы, которые не генерируются. Я вижу, что это делается все время, и это не так плохо, как вы думаете. Определенно какая-то ворчание, но также дает гибкость.

Следует ли нам кэшировать схему ввода при запуске (это беспокоит меня, потому что она добавляет много накладных расходов для запуска приложений консоли)?

Вы хотите создать бизнес-объекты на основе ваших сущностей при загрузке приложения? Или другой способ формулировки вопроса ... генерировать прокси-классы во время выполнения?

Answer 2

Я не знаком с книгой Лен Сильверстона, и я полагаю, что ни один из них не является подавляющим большинством пользователей StackOverflow. Поскольку вы не получили ответы на свой вопрос в течение 3 дней, я сейчас прокомментирую его.

Что меня поразило в вашей модели базы данных, так это то, что у вас, похоже, есть несколько вложенных отношений N: M. Там редко встречаются истинные отношения N: M - в большинстве случаев промежуточная таблица в реляционной модели N: M фактически представляет объект, который существует в реальной жизни, оставляя вас с двумя регулярными отношениями 1: N и более чем двумя столбцами в таблицу ссылок. За последние 25 лет я столкнулся с одним или двумя истинными отношениями N: M, поэтому я сомневаюсь, что у вас на самом деле есть три здесь. Вероятнее всего, вы используете шаблон, который не применяется в как вы думаете.

То, что вы описываете, немного пахнет, как будто вы пытаетесь смоделировать базу данных в базе данных. Особенно: «Должны ли мы сначала сгладить нашу базу данных в более дружественные .NET-представления, которые по существу моделируют наши бизнес-объекты?» звучит подозрительно. За очень немногими исключениями таблицы базы данных должны соответствовать вашим бизнес-объектам для начала. Если вам нужно создать сплющенный вид, чтобы увидеть ваши фактические объекты, вы можете полностью двигаться в неправильном направлении. Но опять же, трудно сказать из информации, которую вы дали.

Просьба дать менее абстрактное описание того, что вы пытаетесь сделать, что вы сделали до сих пор.