Советы по поводу подходящего проектирования и реализации базы данных с C #

Question

Таблица магазинов: таблица для хранения информации о разных магазинах

StoreId     Name       PlaceCode  
--------    --------   --------     
1           Addidas     AB1         
2           Nike        KS3         
3           Puma        LS6         
4           Nike        AS2         
5           Nike        WR4

Таблица областей

AreaId   Area
------   -------
1        DownTown
2        UpTwon

Таблица магазинов: Редактировать

StoreId   AreaId
-------   -------
1         1
2         2
3         2
4         1
5         2

Nike, например, имеет больше, чем филиал для своего магазина поэтому моя идея заключалась в том, чтобы иметь больше, чем запись с атрибутом имени «nike», но другие атрибуты будут содержать информацию о ветви.

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

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

Я думаю, что эта информация будет:
1 - PlaceCode филиала
2 - Чтобы я мог предоставить URL с помощью строки запроса для доступа ко всем другим ветвям? StoreId = Id
3 - площадь филиала
чтобы перейти прямо к точке, я хочу, чтобы на подробной странице любого данного магазина было поле с названием ветки, в котором будет отображаться область филиала + код места всех других доступных филиалов. Например, "Филиалы: Центр города: AS2" и слово "Центр города" будут доступны для ссылки на филиал!

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

Answer 1

Как правило, я рекомендую использовать бизнес-язык для определения ваших программных концепций. Итак, я бы использовал слово «ветвь», чтобы определить конкретное, физическое место, где люди могут покупать вещи. Я бы сделал определение этого общего бизнес-языка почти первым шагом в проекте.

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

• Есть много компаний (Nike, Adidas и т. Д.)
• У каждой компании есть один или несколько филиалов.
• Филиал имеет один и только один код города.
• Один код города может иметь 0 или более филиалов.

В этом случае модель является первым решением, которое предлагает Эрик Т (извините, что я не использую те же имена, что и он).

В частности:

Стол КОМПАНИИ

COMPANY_ID     NAME
---------------------
1              Nike
2              Adidas
3              Reebok

Стол AREA

AreaId   Area
------   -------
1        DownTown
2        UpTown

Стол ФИЛИАЛ

BRANCH_ID       COMPANY_ID       AREA_ID       ADDRESS
-------------------------------------------------------
1               1                1             The Mall
2               1                2             High Street
3               2                1             Near MacDonalds
4               3                2             Out of town

Чтобы найти другие магазины компании для данного филиала, вам нужен только ID филиала:

select *
from branch
where company_id =
 (select company_id from branch where branch_id = %current_branch_id%

Answer 2

Kashef,

Каждый магазин находится только в одном регионе, верно? Если это так, создайте таблицу хранилища с отношением внешнего ключа к таблице регионов (т.е. RegionID в таблице хранилищ).

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

Установка будет выглядеть как

Таблица регионов ---> Магазины <---- Компания </p>

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

Erick

Отредактировано на основе комментариев

В этом случае, что вам действительно нужно, отношения «многие ко многим» между регионами и хранилищами с отдельным первичным ключом (т.е. не RegionID + StoreID).

Таблица регионов ---> RegionTable <--- Магазины <---- Компания </p>

Это позволит вам иметь несколько магазинов в одном регионе. Тем не менее, он также позволяет несколько регионов для одного магазина! Возможно, вы сможете обойти это с помощью ограничения, которое гарантирует, что у каждого магазина только один регион.

Имеет ли это смысл?

Erick