Как разработать таблицу product для многих видов продукта, где каждый продукт имеет много параметров
Ваш скрипт выглядит так в псевдокоде:
START
IF outside workinghours
EXIT
ELSE
RUN /Restore FOR EACH backupdir
GOTO START
Скрипт проверяет время только один раз, прежде чем запустить restore прогон (который будет вызывать /Restore для каждого каталога, который нужно восстановить в цикл for) Он продолжит запуск цикла for, пока не начнется рабочее время. Затем он выйдет.
например. если у вас есть 3 папки для восстановления, каждая занимает 2 часа; и вы запускаете сценарий в полночь; затем скрипт проверит, не в нерабочее ли оно время (и есть), и начнет восстановление для первой папки (в 0:00), после двух часов работы он начнет восстановление 2-й папки (в 2:00) еще через два часа начнется восстановление 3-й папки (на 4:00). Как только третья папка будет восстановлена, она снова проверит рабочее время. Поскольку теперь это только 6:00, то есть: вне рабочих часов, он начнет восстановление для первой папки (в 6:00), после двух часов работы он начнет восстановление 2-й папки (в 8:00 ), еще через два часа начнется восстановление 3-й папки (на 10:00). Это полдень, когда он делает следующую проверку рабочего времени; поскольку 12:00 находится в пределах 7:00 .. 17:00, сценарий теперь остановится. С сообщением об ошибке.
Возможно, вы хотите, чтобы восстановление запускалось только один раз для каждой папки, и перестаньте переходить к следующей папке, если начнется рабочее время.
#!/bin/bash
for path in /backup_local/ARCHIVES/EAR_*/; do
currenttime=$(date +%H:%M)
if [[ "$currenttime" > "7:00" ]] && [[ "$currenttime" < "17:00" ]]; then
echo "Not restoring inside working hours!" 1>&2
break
fi
dirname="$(basename "${path}")"
/Restore -a /backup_local/ARCHIVES -c -I 0 -force -v > /backup_local/$dirname.txt
# handle exit code
done
обновление
Я только что заметил ваш либеральный разброс & для фоновых заданий. Предположительно это позволяет запускать скрипт из удаленной оболочки. не
Что это действительно будет делать:
- будет выполнять все итерации по каталогам восстановления параллельно. Это может создать узкое место в вашем хранилище (если каталоги для восстановления на / с совместно используют одно и то же оборудование)
- это будет фоновый весь цикл восстановления и немедленно вернется к проверке вне часов. если проверка прошла успешно, она создаст другой цикл для восстановления (и фон его). затем он вернется к проверке в нерабочее время и вызовет другой фоновый цикл для восстановления. До рассвета у вас, вероятно, несколько тысяч фоновых потоков для восстановления каталогов. Скорее всего, вы превысили свои ресурсы и процесс был убит.
В моем примере скрипта, приведенном выше, пропущены все фоновые изображения (и nohup).
Если вы хотите запустить скрипт из удаленной оболочки (и выйти из оболочки после его запуска), просто запустите его с
nohup restore-script.sh &
В качестве альтернативы вы можете использовать
echo "restore-script.sh" | at now
или использовать cron-job (если применимо)
2 ответа
У Вас есть, по крайней мере, эти пять опций для моделирования иерархии типа, которую Вы описываете:
Единственное Наследование Таблицы: одна таблица для всех Типов продукта, с достаточным количеством столбцов для хранения всех атрибутов всех типов. Это означает много столбцов, большинство которых является ПУСТЫМ на любой данной строке.
Наследование Таблицы класса: одна таблица для продуктов, храня атрибуты, характерные для всех типов продукта. Затем одна таблица на тип продукта, храня атрибуты, характерные для того типа продукта.
Конкретное Наследование Таблицы: никакая таблица для общих атрибутов продуктов. Вместо этого одна таблица на тип продукта, храня и общие атрибуты продукта и определенные для продукта атрибуты.
Сериализированный LOB: Одна таблица для продуктов, храня атрибуты, характерные для всех типов продукта. Один дополнительный столбец хранит BLOB полуструктурированных данных, в XML, YAML, JSON или некотором другом формате. Этот BLOB позволяет Вам хранить атрибуты, характерные для каждого типа продукта. Можно использовать необычные Шаблоны разработки для описания этого, такого как Фасад и Сувенир. Но независимо у Вас есть блоб атрибутов, которые не могут быть легко запрошены в SQL; необходимо выбрать целый блоб назад к приложению и отсортировать его там.
Значение атрибута объекта: Одна таблица для продуктов и одна таблица, которую центры приписывают строкам вместо столбцов. EAV не является допустимым дизайном относительно реляционной парадигмы, но многие люди используют его так или иначе. Это - "Шаблон Свойств", упомянутый другим ответом. Посмотрите, что другие вопросы с eav наклеивают StackOverflow для некоторых ловушек.
Я записал больше об этом в презентации, Расширяемом Моделировании данных.
Дополнительные мысли о EAV: Хотя многие люди, кажется, одобряют EAV, я не делаю. Это походит на наиболее гибкое решение и поэтому лучшее. Однако имейте в виду пословицу TANSTAAFL. Вот некоторые недостатки EAV:
- Никакой способ сделать столбец обязательным (эквивалентный из
NOT NULL). - Никакой способ использовать типы данных SQL для проверки записей.
- Никакой способ гарантировать, что названия атрибута последовательно записываются.
- Никакой способ поместить внешний ключ на значения любого данного атрибута, например, для справочной таблицы.
- Выборка результатов в стандартном табличном расположении является сложной и дорогой, потому что для получения атрибутов от нескольких строк необходимо сделать
JOINдля каждого атрибута.
Степень гибкости, которую EAV дает Вам, требует жертв в других областях, вероятно, делая Ваш код как комплекс (или хуже), чем это должно было бы решить исходную проблему более стандартным способом.
И в большинстве случаев, является ненужным иметь ту степень гибкости. В вопросе OP о типах продукта намного более просто составить таблицу на тип продукта для определенных для продукта атрибутов, таким образом, у Вас есть некоторая последовательная структура, осуществленная, по крайней мере, для записей того же типа продукта.
Я использовал бы EAV, только если каждой строке нужно разрешить потенциально иметь отличный набор атрибутов. Когда у Вас есть конечное множество типов продукта, EAV является излишеством. Наследование Таблицы класса было бы моим предпочтительным вариантом.
Обновление 2019: Чем больше я вижу, что люди используют JSON в качестве решения для "многих пользовательских атрибутов" проблема, тем меньше мне нравится это решение. Это делает запросы слишком сложными, даже когда с помощью специальных функций JSON для поддержки их. Требуется намного больше пространства памяти для хранения документов JSON, по сравнению с хранением в нормальных строках и столбцах.
В основном ни одно из этих решений не легко или эффективно в реляционной базе данных. Вся эта мысль о наличии "переменных атрибутов" существенно противоречит реляционной теории.
То, к чему это сводится, - то, что необходимо выбрать одно из решений, на основе которых наименее плохо для приложения. Поэтому необходимо знать, как Вы собираетесь запросить данные перед выбором проектирования баз данных. Нет никакого способа выбрать одно решение, которое является "лучшим", потому что любое из решений могло бы быть лучшим для данного приложения.
У Вас могут быть Таблица product и отдельная таблица ProductAdditionInfo с 3 столбцами: идентификатор продукта, дополнительное информационное имя, дополнительное информационное значение. Если цвет используется многими, но не все виды продуктов у Вас мог бы быть он, nullable столбец в Таблице product или просто помещает его в ProductAdditionalInfo.
Этот подход не является традиционной техникой для реляционной базы данных, но я видел, что он использовал много на практике. Это может быть гибко и иметь хорошую производительность.
Steve Yegge называет это шаблоном Свойств и записал длинное сообщение об использовании его.