Динамическое создание таблиц mysql на основе критериев в ruby on rails 5

Question

Динамическое создание таблиц mysql на основе критериев в ruby on rails 5

0

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

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

Padu 06 фев. 2018, в 18:08

Источник

2

Вам не нужна таблица для домена, которая нарушает принципы реляционного проектирования. Вместо этого поместите все в одну таблицу с колонкой, указывающей источник домена.
tadman 06 фев. 2018, в 17:07
0

Разве это не создаст очень неэффективную базу данных для сравнения изменений из того же домена, если, например, страницы очищаются каждые несколько часов и хранятся в одной и той же таблице?
Padu 06 фев. 2018, в 17:10
0

Вот для чего нужны индексы. Они облегчают поиск по подмножеству данных для того, что вы хотите. Вы также хотите хэшировать содержимое, которое вы получаете, чтобы вы могли пропустить дублированные вставки. Если хэш содержимого совпадает, игнорируйте его, не сохраняйте его, так как у вас уже есть снимок этой версии.
tadman 06 фев. 2018, в 17:12
0

Приветствую за быстрые ответы и советы, я буду использовать только одну таблицу, как вы предложили, и хэшировать данные.
Padu 06 фев. 2018, в 17:14
1

Вы будете приятно удивлены тем, сколько данных может создать простая база данных и при этом работать хорошо. Если у вас есть проблемы с масштабированием, подумайте об использовании разделов для управления вещами. Переход на несколько таблиц дает вам быстрые победы («да, меньше данных на таблицу!»), Но вскоре оказывается совершенно неуправляемым («он ломает мой клиент SQL, когда я перечисляю все базы данных»).
tadman 06 фев. 2018, в 17:15

Показать ещё 3 комментария

Теги:

mysql

database

ruby-on-rails

ruby

1 ответ

Ещё вопросы

Вам не нужна таблица для домена, которая нарушает принципы реляционного проектирования. Вместо этого поместите все в одну таблицу с колонкой, указывающей источник домена.
Разве это не создаст очень неэффективную базу данных для сравнения изменений из того же домена, если, например, страницы очищаются каждые несколько часов и хранятся в одной и той же таблице?
Вот для чего нужны индексы. Они облегчают поиск по подмножеству данных для того, что вы хотите. Вы также хотите хэшировать содержимое, которое вы получаете, чтобы вы могли пропустить дублированные вставки. Если хэш содержимого совпадает, игнорируйте его, не сохраняйте его, так как у вас уже есть снимок этой версии.
Приветствую за быстрые ответы и советы, я буду использовать только одну таблицу, как вы предложили, и хэшировать данные.
Вы будете приятно удивлены тем, сколько данных может создать простая база данных и при этом работать хорошо. Если у вас есть проблемы с масштабированием, подумайте об использовании разделов для управления вещами. Переход на несколько таблиц дает вам быстрые победы («да, меньше данных на таблицу!»), Но вскоре оказывается совершенно неуправляемым («он ломает мой клиент SQL, когда я перечисляю все базы данных»).

tadman · Accepted Answer · 2018-02-06T15-35-00.000Z

Рекомендуемый способ "реляционной базы данных" - это иметь уникальную таблицу и связывать эту таблицу с исходным кодом. Для моментальных снимков страниц вы часто можете хэшировать содержимое для проверки дублированных данных, а индекс UNIQUE в хеше содержимого может автоматически предотвращать подобные сортировки.

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

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

Если вам нужно сохранить снимки страниц по диагностическим или историческим причинам, таблица будет работать. Чтобы сохранить размер, вы можете исследовать его с помощью таблицы типа ARCHIVE. Они являются только добавлением, вы не можете редактировать их, но они компактны и хорошо работают.

Вы можете периодически TRUNCATE таблицу такого типа, чтобы очистить старые данные, чтобы вы не оставляли мусор навсегда.

Спасибо, я уже использую Nokogiri, и я буду больше читать о таблицах ARCHIVE, так как я хочу вести записи.