Рассматривая новое приложение Rails с существующими данными (не БД, фактическими данными) - как лучше всего продолжить?

Question

Передо мной была поставлена ​​задача разработать новый розничный магазин электронной коммерции для моей текущей работы, и я подумываю заняться им с RoR to A) Создать «настоящий» проект с моими ограниченными знаниями Rails и B) Быстро дать руководству Оборот и обратная связь (они хотят сделать это как можно скорее, и их сроки довольно нереалистичны - я говорю пару недель, чтобы перейти от ничего к рабочей модели, чтобы они могли начать продавать ее с SEO / SEM и, я шучу вам нет, «видеоблоги», потому что мой начальник слышал, что это будущее).

У нас есть структура базы данных, но она абсолютно ужасна и была собрана без всяких на то оснований, поэтому я собираюсь в значительной степени игнорировать ее и создать новую базу данных с нуля; однако у меня есть существующие данные, которые мне нужно загрузить в приложение (как я уже сказал, это приложение для электронной коммерции, и у нас есть данные о продукте). Мне нужно преобразовать эти данные в удобный для использования формат, потому что наш поставщик предоставляет нам загадочные, сокращенные имена столбцов, и они сильно денормализованы, особенно в категориях (я уже писал об этом раньше - в основном таблица категорий имеет шесть полей). по одному для каждой категории / подкатегории, причем некоторые из них будут пустыми, если эта категория не применяется).

Есть две основные проблемы, которые заставляют меня задуматься:

1. Как я уже сказал, данные должны быть помещены в "правильную" схему базы данных; Я не могу просто загрузить его как есть. У меня есть некоторые мысли относительно хорошей модели данных для нее, но мой анализ еще не завершен. В конечном итоге будет создано большое количество таблиц объединений для связи разных вещей (например, products_categories, products_attributes, products_prices) и т. Д., И эти таблицы будут связывать товары не по идентификатору, а по их SKU (см. Ниже).

2. У всего уже есть идентификатор, который сгенерирован для него, но для всего нового, что я добавляю, нужен один автоматически; Я сомневаюсь, что это будет проблемой для любой зрелой СУБД, но я знаю, что Rails любит генерировать идентификаторы самостоятельно. Кроме того, почти все таблицы, относящиеся к продукту, связаны между собой SKU (а в данных, предоставленных поставщиком, на самом деле составной ключ, состоящий из префикса и номера запаса, которые вместе составляют полный SKU), а не по ID и I. Я не уверен, если это будет проблемой производительности (конечно, я всегда мог вручную создавать индексы для этих столбцов, чтобы ускорить его). Однако это означает, что мне нужно отойти от соглашений Rails.

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

Answer 1

Я бы разработал приложение, как если бы у вас не было данных. Используйте ORM и сделайте свою базу данных максимально возможной, но, конечно, имейте в виду, какими данными вы должны ее заполнить (например: не устанавливайте новые безумные ограничения для вещей, которые позволят вам просматривать старую запись данных за записью ).

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

Это ничем не отличается от обычной модели проектирования / разработки ... Кроме того, вы можете вводить данные полуавтоматическим способом.

Answer 2

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

Не думайте, что существующие данные действительны только потому, что они уже есть.

Answer 3

Не используйте SKU в качестве уникального ключа для каждого продукта - используйте стандартный увеличенный идентификатор Rails.

SKU может измениться, так как он может быть неверно введен и т. Д., И это приведет к кошмарному изменению всех ссылок из других таблиц. Поместите ваш текущий идентификатор в столбец sku, проиндексируйте его и обновите ссылки в других ваших таблицах на идентификаторы Rails.

Вы сможете использовать Product.find_by_sku (params [: sku]) в своих контроллерах, настроить маршрут / products /: sku и т. Д. Я не вижу, что вы получите (кроме головная боль), используя ваши не сгенерированные идентификаторы в качестве первичных ключей базы данных.

Answer 4

Я был в той же ситуации не так давно - дрянное PHP-приложение, в котором хранилось десять лет всех данных компании.

Я просто создал модель миграции и добавил методы для импорта каждого ресурса.

class Migration
  def migration_all
    self.jobs
  end

  def self.jobs
    ...
  end
end

Крутая вещь в этом заключается в том, что вы можете указать, какие ресурсы заказа импортируются, поскольку один, скорее всего, будет ссылаться на другой. Я также добавил методы, которые напрямую модифицировали схему БД. Один хороший трюк, если вам нужно сохранить существующий первичный ключ, это создать поле с именем 'legacy_id', скопировать существующий первичный ключ, а когда вы закончите, просто удалите поле 'id', переименуйте поле 'legacy_id' в 'id', затем добавьте ограничение primary_key в новое поле 'id'.