Делаем на стажировке интернет магазин. База данных на sql server, а сайт будем делать на asp.net mvc 5.
На данный момент база выглядить следующим образом:

Поскольку будем пользоваться пакетом Microsoft.Asp.Identity, 5 таблиц было сгенерировано EntityFramewor-ком вместо нам, а именно: AspNetRoles, AspNetUserRoles, AspNetUsers, AspNetUserLogins, AspNetUserClaims.
Интересуют правильно ли я наладил связи между таблицами.
Отвечу на любые вопросы если таковые возникнут.
Так же хотел бы спросить. В таблице Orders, у меня есть атрибут OrderStatus. Его дефиниция выглядит следующим образом:


Сделал я это с намерением, при моделировании сущьности создать enum из этих значений. Насколько целесообразна такая практика.

Сейчас на прогулке на свежем воздухе, сразу же обнаружил банальную ошибку, а именно, вместо отношения много-ко-многим между Orders и Products, у меня было связь один-ко-многим. Исправил. Заодно выложу SQL, может будет кому удобнее просматривать в Management Studio

Владимир П., Большое спасибо за отзыв. В первую очередь ставя check на поле, я хотел избежать создание новой таблицы, руководствуясь тем, что записи в неё добавляться на вряд ли будут, а значит лучше нам сэкономить на Join. Но ваш вариант, как я считаю более приемлив, так как мы тем самым, обезопасиваем от ввода ложных данных, к тому же джойни так же можно избежать, просто запомнив аббревиатуры.
Кое какие детали при проектировании я конечно упустил, так как, делал сначала на листике..возможно глупо, но я так привык.
Например в Products нужно ввести текущую цену продукта. Она ведь может изменится. Как в таком случае поступить? Вкрадывается идея сделать отдельную таблицу, которая по внешнему ключу будет держать id продукта, и добавить триггер на Update, в случае изменения цены, что бы добавлялась строка с предыдущей стоимостью товара. Однако, Orders могут содержать несколько продуктов, то есть перед самым оформлением заказы, надо будет как то проверить а не изменилась ли цена продукта, держать булевый атрибут для каждой записи мне кажется не очень целесообразным, ведь цена товара не так часто меняется. Вот как это реализовать?
Будет ещё один вопрос по поводу именования. Атрибут Ordered в таблице Orders, на данный момент у меня отражает дату заказа. Было бы более понятно если бы мы переименовали название в OrderDate?

Dimitry Sibiryakov, Нет разумеется, просто я бд больше 5 таблиц никогда не делал, вот и экспериментирую. Что насчёт другого вопроса? Можно услышать Ваше мнение по этому поводу.

Dimitry Sibiryakov, Да, Вы правы, с комментариями ошибка вышла, один продукт может иметь много комментариев, и один комментарий может принадлежать одному продукту, значит отношение один-ко-многим.
На счёт продуктов и заказов, логика следующая..представим себе что пользователь добавляет множество продуктов в корзину, перед тем как окончательно оформить заказ, надо проверить а не изменилась ли цена на какой-то продукт, если цена была изменена вывести пользователю предупреждение об изменении, если пользователь согласен с изменением цены на конкретный продукт, суммировать общую стоимость всех выбранных продуктов и сформировать окончательную цену и записать её в Заказы.
Теперь как отобразить логику в бд об изменении цены? К тому же, например, у нас в наличие 100пар обуви, кто то и заказчиков купил 15, значит мы должны отобразить как-то что теперь по этому продукту у нас осталось 85пар.

Dimitry Sibiryakov,
авторCategories, Child Categories (tree structure), Name, Description, Create/Update/Delete Branch (delete category and child categories)
Products in 1 category, Name, Description, Price, Quantity, Active...
Tags - each product can have multiple tags
Users (registration, no external login) - use ASP.NET Identity
- Admin role - can promote other admins
- Product Manager - can create new products and edit products
- Moderator can delete comments on products
- Seller can mark orders as completed
- Everyone can buy things and post comments
Comments on products (flat), no anonymous comments, Text, Author, IP Address, IsDeleted (do not delete comments just hide them) - comments are added via pure client side AJAX (no action links, just jQuery)
Product list, filter by category search in name (Use LIKE), paging, filters in URL, when the user opens the URL he should immediately see the product list (search engine friendly), the URLs should change even when the page is changed via AJAX
Orders - customers can place orders, orders record the items, the current price at the moment of the order, the address of the customer in the moment of the order, checks if the customer has address, a Seller can mark the order as new, in progress or completed, the customer can see the status of the order

Admin Panel for managing users, seeing deleted comments, choose front-end technology (Angular, Angular2, React, Ember...), backend with ASP.NET WebAPI


Нам ТЗ ментор написал за 5минут, так что очень много чего мы будем походу работы добавлять и дорабатывать. Я честно говоря не знаю как поступить.

Dimitry Sibiryakov, Я не много запутался, отношение между Заказами и Продуктами много-ко-многим должно быть? В задании сказано 'orders record the items'. У меня как такой таблицы items нету, я подразумевал что продукт это есть наши items.
На данный момент БД после всех исправлений выглядит во так:

Пропустил один пункт. Есть у нас таблица Categories, у которой атрибут ParentId является внешним ключом на таблицу Categories, тем самым мы реализуем древовидную структуру. Как нам реализовать удаление категории? То есть если мы удаляем один из листьев дерева, то разумеется никаких проблем. В случае же если на наш узел ссылаются, то удаление запрещено. Вешать ON CASCADE DELETE на внешний ключ запрещает SQL Server. Остаётся два варианта, триггер или процедура.
Поскольку триггер использует по умолчанию операцию AFTER, то есть мы его вешаем на операцию DELETE то ничего не достигаем, потому как удаление узла на который ссылаются, запрещено. Значит надо использовать INSTEAD OF, да же всё получилось реализовать. Вот только беда что теперь мы в каком то смысле ограничены. Можно удалять теперь запись только по определенному id. Я понимаю, что это конечно маловероятно, но допустим чисто теоретически придётся удалить все записи где в описании категорий будет матерное слово. И в этот момент мы получается ограничены, ведь не можем воспользоваться DELETE.
Остаётся вариант с использованием процедуры, но мои результаты поиска к внятному описанию с реализацией ни к чему не привели. Может кто поделится опытом, что делать в такой ситуации.