Нормализация/Схема для классификации ошибок перекрестного браузера на основе механизмов визуализации и версий браузера?
Я пытаюсь выбрать схему для хранения ошибок перекрестного браузера через все механизмы визуализации.
Вот то, что я имел в виду:
таблица browser_engines:
id name version
1 gecko 1.5
2 gecko 1.7
3 gecko 1.8
4 gecko 1.9.0
5 gecko 1.9.1
таблица browser_versions:
id name version engine_id
1 firefox 3.0 4
2 firefox 3.5 5
таблица browser_bugs:
id name description engine_id
1 ff bug 4
Таким образом, если бы я вытянул первую ошибку, то она отобразилась бы на геккона 1.9.0, таким образом, представление HTML представило бы браузер, затронутый как Firefox 3.0.
Вопрос 1.1: эта схема имеет смысл? Это нормализовано достаточно?
Вопрос 1.2: Каков тип данных столбец версии должен быть?
2 ответа
Вопрос 1.1: Имеет ли смысл эта схема? Достаточно ли она нормализована?
Эй! Это два вопроса. ;-)
Эта схема предполагает некоторые вещи, такие как:
- Каждая версия браузера имеет только один браузерный движок.
- Каждая ошибка в данном движке браузера гарантированно влияет на каждый браузер, который использует этот движок.
Если одно из этих предположений не всегда гарантированно верно, вам могут понадобиться таблицы пересечения "многие-ко-многим".
Вопрос 1.2: Каким типом данных должен быть столбец версии?
Я бы выбрал VARCHAR, чтобы учесть "4.0 release candidate 1" и тому подобное. Я бы разрешил длину не менее 30.
Я бы создал таблицу движка (т.е. одну строку для gecko и FK от browser_engine к движку), аналогично таблице браузера. Это снизит требования к хранилищу и ускорит запросы. Я бы также подумал о том, чтобы сохранить версию в полях major / minor / revision, чтобы упростить поиск «всех ошибок в версии 2.5 или предыдущей» («10.0» <«2.5» - поэтому строки не подходят для такого запроса).