В настоящее время мы разрабатываем сайт для онлайн-рекламы для людей, которые покупают и продают (аналогично gumtree), поскольку это будет использоваться для сотрудников, работающих в компании, это не будет доступно для людей за пределами Компания.Разбиение таблиц в SQL Server 2008
Теперь у нас есть 15 категорий, которые имеют подкатегории, и эти подкатегории имеют дочерние категории.
У нас есть главная таблица под названием Объявления, которая состоит на ItemId, заголовок, подзаголовок, описание, CreatedBy, BroughtBy, StartDate, EndDate и ParentCategoryId, SubCategoryId и ChildCategoryId т.д.
Теперь вместо того, чтобы один массивные таблицы, состоит из все детали для предмета, который они продают, мы собирались создать отдельную таблицу (ы) для каждой категории для деталей элемента.
Таким образом, мы имели бы Advert.Vehicle_Spec, который бы все подробности о машине они продавали т.е. ItemId (который будет FK к главной таблице) Сейчас, Марка, модель, цвет, Мот, Налоги и т.д.
Таким образом, когда мы запрашиваем основную таблицу объявлений, мы можем присоединиться к соответствующей таблице Spec, которая в некотором смысле сохранит таблицы в чистоте и порядке, теперь мой вопрос будет для вас хорошим? Будут ли какие-либо проблемы с производительностью при таком подходе? Я создам все соответствующие FK, где необходимо, чтобы помочь с запросами и т. Д.
Я задал этот вопрос на форуме SQL Server, а один из них предложил использовать XML - каждая категория получает XML-схему, а теги и значения XML хранятся в одном поле, но данные варьируются в зависимости от того, какой тип товара продается. Это требует большей настройки, но, вероятно, имеет наилучший общий баланс производительности и гибкости, я лично никогда не работал с XML в SQL, поэтому я не могу прокомментировать, что это хороший подход или нет?
В каждой категории может быть много разных статусов, у нас есть множество таблиц, которые содержат описание каждого состояния, запросы, которые мы будем выполнять, будут варьироваться в зависимости от выбора, удаления, вставки, обновления, некоторые запросы будут иметь несколько подключений к в таблице «Статус/Пользователь» мы также будем внедрять «Рекомендуемую» форму, в которой будут отображаться все записи, предлагаемые пользователю в зависимости от того, что они ищут.
Правильно ли это XML в отношении гибкости и производительности?
Единственное соображение с этим подходом состоит в том, что вам, возможно, потребуется тщательно подумать об ограничениях и целостности внешнего ключа. Я не думаю, что вы можете применять ограничения внешнего ключа в XML. –
Скотт дал ItemID как обычный столбец, например, он может просто использовать Внутренние Соединения для запроса подкатегорий на условиях, в которых они равны, проблема связана с использованием XML PATH/XML AUTO и т. Д., А затем при отображении данных в таблице с использованием XSLT. –
@LebronJames извините за поздний ответ, выше, кажется, правильный подход, для хранения этой информации в БД, как я мог ее структурировать? i.e datatype и т. д., следует ли распространять таблицу Adverts на один столбец, который будет содержать это значение XML? Я нашел это, но я не уверен, что это то, о чем вы говорите о http://msdn.microsoft.com/en-us/library/ms176009.aspx –