Сложное управление базой данных

Question

Я рисую очень простой дизайн базы данных для своего приложения ASP.NET и с небольшой помощью тут и там мне удалось реализовать свой дизайн ... но я хочу вставить данные в эти таблицы и извлечь из них.

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

Мои вопросы:

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

PS: между каждыми двумя таблицами, имеющими (M: M) отношение, рассмотрим третью таблицу (которая будет иметь два первичных ключа каждой из 2 таблиц в отношении).

Я знаком с JOINs и всем, но никогда не использовал такой большой дизайн ... ПОМОГИТЕ! Заранее спасибо!

Answer 1

Извините, что напугал вас, но это очень маленький дизайн базы данных.

Когда я впервые начал нуждаться в разработке базы данных для веб-приложений, я обнаружил опору. К счастью, костыль, который я использовал тогда, теперь доступен в бесплатном инструменте NORMA , который работает с Visual Studio 2008 или 2005 (ожидается поддержка 2010).

Я быстро догадался о вашем дизайне и получил следующую модель ORM:

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

Инструмент NORMA может генерировать DDL из модели для нескольких различных баз данных, а также может создавать схемы XML и объекты LINQ to SQL.

---

Кстати, вот диаграмма ER сгенерированной базы данных:

---

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

SELECT k.KidId, k.Name, k.FavoriteToy, 
    s.SponsorId, s.Name, 
    st.SponsorShipTypeCode, st.Description AS SponsortshipTypeDescription,
    fw.FieldOfWorkCode, fw.Description AS FieldOfWorkDescription,
    Skill.SkillCode, Skill.Description AS SkillDescription,
    Parent.ParentId, Parent.Name AS ParentName
FROM Kid k
LEFT OUTER JOIN KidHasParent ON KidHasParent.KidId = k.KidId
INNER JOIN Parent ON Parent.ParentId = KidHasParent.ParentId
LEFT OUTER JOIN KidHasSkill ON KidHasSkill.KidId = k.KidId
INNER JOIN Skill ON Skill.SkillCode = KidHasSkill.SkillCode
LEFT OUTER JOIN Sponsor s ON s.SponsorId = k.SponsorId
INNER JOIN SponsorIsOfSponsorShipType Sst ON Sst.SponsorId = s.SponsorId
INNER JOIN SponsorShipType st ON st.SponsorShipTypeCode = sst.SponsorShipTypeCode
LEFT OUTER JOIN SponsorParticipatesInFieldOfWork sfw ON sfw.SponsorId = s.SponsorId
INNER JOIN FieldOfWork fw ON fw.FieldOfWorkCode = sfw.FieldOfWorkCode

Я создал этот запрос, взглянув на диаграмму ORM, чтобы узнать, какие пути являются необязательными (LEFT JOIN), а затем с помощью инструмента (ApexSQL Edit), который использует внешние ключи, чтобы помочь мне построить соединения. Это заняло менее десяти минут.

Answer 2

Чтобы попытаться ответить на ваши вопросы:

1. Это довольно маленький дизайн. В моем текущем проекте на работе 150 таблиц, расположенных не так, как у вас.

2. В идеале, чтобы ввести нового ребенка, вам нужно будет только ввести данные в таблицу Kid. Самый простой способ визуализировать это с точки зрения графического интерфейса - это иметь одну таблицу графического интерфейса на таблицу базы данных. Таким образом, вы можете указать родителей, спонсоров, навыки, сферы деятельности и т. Д. В их собственных формах.

3. Вам нужно будет спросить себя, сколько информации необходимо предоставить каждому ребенку в зависимости от потребности. Интерфейс, который показывает список детей с их родителями, любимой игрушкой, спонсорами, навыками и т. Д., Станет слишком переполненным. В зависимости от вашего приложения вы, вероятно, захотите более точно указать, какие данные вы показываете. Например, вы можете перечислить всю информацию для детей, когда вы указываете их по имени. Например, если вам нужно запросить детей, которых спонсируют водопроводчики (области работы спонсоров), вам, возможно, все равно, какая у них любимая игрушка.

Answer 3

1. Это не большой дизайн, а скорее маленький. Вероятно, он будет расти по мере дальнейшего развития приложения.

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

3. Вы получите данные обратно, используя один или несколько операторов SELECT, которые получают данные из одной таблицы или данные JOIN из нескольких разных таблиц. Если вы обнаружите, что эти операторы JOINed SELECT представляют собой важные, часто используемые концепции, вы можете включить их в некоторые VIEW.