Мой работодатель, небольшая канцелярская компания, меняет поставщиков, и я просматриваю их электронный контент, чтобы найти надежную схему базы данных; наша предыдущая схема была в значительной степени просто собрана вместе, не задумываясь, и в значительной степени привела к невыносимой модели данных с поврежденной, противоречивой информацией.
Данные нового поставщика намного лучше, чем у старого, но их данные - это то, что я бы назвал гипернормализованным . Например, их структура категории продуктов имеет 5 уровней: главный отдел, отдел, класс, подкласс, блок продукта. Кроме того, содержимое блока продукта содержит подробное описание, поисковые термины и названия изображений для продуктов (идея состоит в том, что блок продукта содержит продукт и все варианты - например, конкретная ручка может быть выполнена черными, синими или красными чернилами; все они Предметы по сути одно и то же, поэтому они относятся к одному блоку товара). В данных, которые мне предоставили, это выражается в виде таблицы продуктов (я говорю «таблица», но это простой файл с данными) со ссылкой на уникальный идентификатор блока продукта.
Я пытаюсь придумать надежную схему для размещения данных, которые мне предоставлены, поскольку мне нужно будет загрузить их относительно скоро, и данные, которые они мне дали, не соответствуют типу данных, которые они предоставляют для демонстрации на своем образце веб-сайта (http://www.iteminfo.com). В любом случае, я не собираюсь повторно использовать их структуру представления, поэтому это спорный вопрос, но я просматривал сайт, чтобы получить некоторые идеи о том, как структурировать вещи.
В чем я не уверен, так это в том, хранить ли данные в этом формате или нет, или, например, объединить Master / Department / Class / Subclass в одну таблицу «Категории», используя самореферентную связь и ссылку это для блока продукта (блок продукта должен храниться отдельно, поскольку это не «категория» как таковая, а группа связанных продуктов для данной категории). В настоящее время таблица блоков продукта ссылается на таблицу подклассов, поэтому она будет изменена на "category_id", если я объединю их вместе.
Я, вероятно, собираюсь создать витрину электронной коммерции, используя эти данные с Ruby on Rails (или это мой план, во всяком случае), поэтому я стараюсь не зацикливаться позже или иметь раздутые приложения - может быть, я слишком много об этом думаю, но лучше быть в безопасности, чем сожалеть; наши предыдущие данные были настоящей неразберихой и стоили компании десятки тысяч долларов в потерянных продажах из-за непоследовательных и неточных данных. Также я собираюсь немного отойти от соглашений Rails, убедившись, что моя база данных является надежной и применяет ограничения (я планирую делать это и на уровне приложений), так что это тоже нужно учитывать.
Как бы вы справились с такой ситуацией? Имейте в виду, что у меня есть данные для загрузки уже в виде плоских файлов, которые имитируют структуру таблицы (у меня есть документация, в которой говорится, какие столбцы какие и какие ссылки установлены); Я пытаюсь решить, следует ли мне сохранить их в таком же нормированном виде, как они есть в настоящее время, или мне следует попытаться объединить их; Мне нужно знать, как каждый метод будет влиять на то, как я программирую сайт с использованием Rails, поскольку, если я произвожу консолидацию, в одной таблице будет по существу 4 «уровня» категорий, но это определенно кажется более управляемым, чем отдельные таблицы для на каждом уровне, поскольку, кроме Подкласса (который напрямую связан с блоками продуктов), они не делают ничего, кроме как показывают следующий уровень категории под ними. Я всегда теряюсь из-за «лучшего» способа обработки данных, подобных этому - я знаю поговорку «нормализуй, пока не повредит, затем денормализуй, пока не заработает», но мне никогда не приходилось реализовывать это до сих пор.