По описанию это связь многие-ко-многим, несмотря на заголовок. Нужны resources, vulnerabilities и таблица связей с составным уникальным ключом.
Проектирование отношения «один‑ко‑многим» между веб‑ресурсами и их уязвимостями
По описанию это связь многие-ко-многим, несмотря на заголовок. Нужны resources, vulnerabilities и таблица связей с составным уникальным ключом.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
Необходимо спроектировать схему базы данных, в которой один веб‑ресурс может быть связан с множеством уязвимостей, а каждая уязвимость может относиться к различным ресурсам. При этом требуется обеспечить быстрый поиск, например, получение всех уязвимостей, относящихся к конкретному ресурсу.
Ответ
По описанию это связь многие-ко-многим, несмотря на заголовок. Нужны resources, vulnerabilities и таблица связей с составным уникальным ключом.
Минимальная схема:
CREATE TABLE resources (
id bigint PRIMARY KEY, url text NOT NULL
);
CREATE TABLE vulnerabilities (
id bigint PRIMARY KEY, title text NOT NULL
);
CREATE TABLE resource_vulnerabilities (
resource_id bigint REFERENCES resources(id),
vulnerability_id bigint REFERENCES vulnerabilities(id),
PRIMARY KEY (resource_id, vulnerability_id)
);
CREATE INDEX vulnerability_resources_idx
ON resource_vulnerabilities(vulnerability_id, resource_id);
SELECT v.*
FROM resource_vulnerabilities rv
JOIN vulnerabilities v ON v.id = rv.vulnerability_id
WHERE rv.resource_id = $1;
Первичный ключ помогает поиску по ресурсу, обратный индекс — по уязвимости. Если одна уязвимость может обнаруживаться несколько раз на разных путях одного ресурса, нужна отдельная сущность finding с путём, статусом и временем, а не только уникальная пара.