Организация руководства с различными версиями в базе данных MySQL
В настоящее время я создаю веб-страницу с базой данных MySQL, где наше руководство пользователя будет отображаться для клиентов.
У меня проблема с контролем версий, в основном с запросами. Я буду хранить "разделы" руководства в виде строк в базе данных с номером версии в виде столбца для каждого раздела. Поэтому, когда выходит новая версия нашего программного обеспечения, вместо того, чтобы переделывать все руководство, мы можем просто изменить разделы, добавив новую строку (раздел) в базу данных с новым номером версии и добавив тот же "section_id", что и тот, который мы меняются, поэтому он будет знать, какой раздел он заменяет. Это позволит пользователям выполнять поиск и в предыдущих версиях руководства пользователя.
Я прочитал в другом сообщении о переполнении стека, что лучше хранить версии в 3 столбцах в базе данных (основной, вспомогательный, сборка / исправление). Если это так, как я могу запросить базу данных, чтобы показать только самые последние строки "версии" или самые последние предыдущие, если в некоторых разделах нет текущих версий. По сути, мне все еще нужно показать разделы, которые не были изменены в последней версии.
Если есть более простой способ организовать и запросить базу данных, я также хотел бы знать.
Вот визуальный пример базы данных (технически столбец позиции находится в другой таблице с индексом section_id, но это только для примера:
Добавленное изображение этой таблицы выше, в случае, если оно не отображается правильно.
id | имя_раздела | section_id | положение | v_major | v_minor | v_build
1 секция 1 1 2 2 0035 2 секция 4 4 2 1 0027 3 секция 3 2 2 1 0027 4 секция 2 3 2 2 0035 5 секция 3 2 2 2 0035 6 секция 1 1 2 1 0027
В запросе должны быть пропущены идентификаторы №3 и №6, поскольку существует новая версия для замены этого section_id.
Имейте в виду, что мне также понадобится способ запросить более старую версию аналогичным образом.
Я знаю, это звучит сложно, но я действительно надеюсь, что кто-то может помочь мне с этим сложным запросом.
Заранее спасибо.
2 ответа
Не существует универсального правила хранения версий - как обычно, "это зависит" от ваших конкретных потребностей. Нет ничего плохого в одном столбце с именем "версия", если это работает в вашей среде.
Но независимо от того, сколько полей вы используете для управления версиями, обычно возникает желание узнать "текущую" версию. Вот три примера распространенных способов сделать это:
- Сортировать по "номеру версии" (один столбец или все столбцы, соединенные вместе), где наибольшее "число" считается текущим (например, "006.000.0001" больше, чем "005.999.1234")
- Имейте временную метку, связанную с каждой версией (т.е. это "дата вступления в силу"), и затем сортируйте по этой временной метке, считая самую последнюю дату текущей.
- Но что, если у вас есть совершенно новая версия, которая еще не "актуальна"? Вы также можете использовать выделенный столбец флага с именем что-то вроде IS_CURRENT и явно установить значение этого флага в значение "ИСТИНА" или любое другое значение, которое вы хотите указать, какая версия является текущей. Конечно, вы должны убедиться, что одна и только одна версия помечается как текущая, но это не должно быть слишком сложным.
Использование любого из этих методов позволяет: 1) идентифицировать текущую версию и 2) по-прежнему иметь в наличии все предыдущие версии, если / когда они необходимы.
Единственная причина иметь несколько столбцов версий заключается в том, что порядок сортировки будет неточным с одной строкой. Это часто имеет место, хотя 2.10.1 является более новым, чем 2.2.50, но не лексически. Я думаю, что это то, что вы после:
SELECT
CAST(SUBSTRING_INDEX(GROUP_CONCAT(DISTINCT id ORDER BY v_major DESC, v_minor DESC, v_build DESC), ',', 1) AS UNSIGNED)
FROM tbl
GROUP BY section_name, section_id
Он получает самый последний идентификатор для каждой пары (section_name, section_id). Если вам нужно больше столбцов, вы можете использовать это как подзапрос. Я бы использовал что-то вроде этого, чтобы пересчитать, какие строки являются текущими, если вам нужно кэшировать их для скорости (уменьшает человеческие ошибки). Если вы имеете в виду целевую версию, вы даже можете защитить ее в предложении WHERE:
WHERE v_major <= 2 AND IF(v_major = 2, v_minor <= 1, 1) AND IF(v_major = 2 AND v_minor = 1, v_build <= 27, 1)