Как разработать схему базы данных для поддержки меток с категориями?
В вашем VC1 создайте переменную как vcNames.
class VC1: UIViewController {
var vcNames = ""
override func viewDidLoad() {
super.viewDidLoad()
//Check your vc's with vcNames.
}
}
Теперь, нажимая на vc1 из VC2 или VC3, просто передайте свое текущее имя vc с созданной переменной.
let tempVC1 = UIStoryboard.init(name: "Main", bundle: Bundle.main).instantiateViewController(withIdentifier: "VC1") as? VC1
tempVC1?.vcNames = "vc2" //Assign your vc name here
self.navigationController?.pushViewController(tempVC1!, animated: true)
4 ответа
Это - еще одна вариация на дизайн Значения атрибута объекта.
Более распознаваемая таблица EAV похожа на следующее:
CREATE TABLE vehicleEAV (
vid INTEGER,
attr_name VARCHAR(20),
attr_value VARCHAR(100),
PRIMARY KEY (vid, attr_name),
FOREIGN KEY (vid) REFERENCES vehicles (vid)
);
Некоторые люди сила attr_name сослаться на справочную таблицу предопределенных названий атрибута, ограничить хаос.
То, что Вы сделали, просто распространено таблица EAV более чем три таблицы, но не улучшая порядок Ваших метаданных:
CREATE TABLE vehicleTag (
vid INTEGER,
cid INTEGER,
tid INTEGER,
PRIMARY KEY (vid, cid),
FOREIGN KEY (vid) REFERENCES vehicles(vid),
FOREIGN KEY (cid) REFERENCES categories(cid),
FOREIGN KEY (tid) REFERENCES tags(tid)
);
CREATE TABLE categories (
cid INTEGER PRIMARY KEY,
category VARCHAR(20) -- "attr_name"
);
CREATE TABLE tags (
tid INTEGER PRIMARY KEY,
tag VARCHAR(100) -- "attr_value"
);
Если Вы собираетесь использовать дизайн EAV, Вам только нужно vehicleTags и categories таблицы.
CREATE TABLE vehicleTag (
vid INTEGER,
cid INTEGER, -- reference to "attr_name" lookup table
tag VARCHAR(100, -- "attr_value"
PRIMARY KEY (vid, cid),
FOREIGN KEY (vid) REFERENCES vehicles(vid),
FOREIGN KEY (cid) REFERENCES categories(cid)
);
Но имейте в виду смешивание данных с метаданными. Вы теряете способность применить определенные ограничения к Вашей модели данных.
- Как можно сделать одну из категорий обязательной (стандартный столбец использует a
NOT NULLограничение)? - Как можно использовать типы данных SQL для проверки некоторых значений тега? Вы не можете, потому что Вы используете длинную строку для каждого значения тега. Эта строка достаточно долго для каждого тега, в котором Вы будете нуждаться в будущем? Вы не можете сказать.
- Как можно ограничить некоторые теги к ряду разрешенных значений (стандартная таблица использует внешний ключ для справочной таблицы)? Это - Ваш "softtop" по сравнению с примером "автомобили с откидным верхом". Но Вы не можете сделать ограничение на
tagстолбец, потому что то ограничение относилось бы ко всем другим значениям тега за другие категории. Вы эффективно ограничили бы объем двигателя и цвет краски к "автомобили с откидным верхом" также.
Базы данных SQL не работают хорошо с этой моделью. Чрезвычайно трудно разобраться, и запросы его становятся очень сложными. Если Вы действительно продолжите использовать SQL, то Вы будете более обеспеченным моделированием таблиц традиционно с одним столбцом за атрибут. Если у Вас есть потребность иметь "подтипы", затем определяют зависимую таблицу на подтип (Наследование Таблицы Класса) или иначе используют Наследование Единственной Таблицы. Если у Вас есть неограниченная вариация в атрибутах на объект, то используйте Сериализированный LOB.
Другая технология, которая разработана для этих видов жидкости, нереляционные модели данных, является Семантической Базой данных, храня данные в RDF и запрошенный с SPARQL. Одним бесплатным решением является Сезам.
Один путь состоял бы в том, чтобы немного заново продумать Вашу схему, нормализовав ключи тега далеко от значений:
vehicles
int vid
string vin
tags
int tid
int cid
string key
categories
int cid
string category
vehicleTags
int vid
int tid
string value
Теперь все, в чем Вы нуждаетесь, является ограничением на уникальность данных на vehicleTags(vid, tid).
С другой стороны, существуют способы создать ограничения вне простых внешних ключей: в зависимости от Вашей базы данных можно ли записать пользовательское ограничение или вставить/обновить триггер для осуществления уникальности тега механизма?
Я думаю, что Ваше решение состоит в том, чтобы просто добавить столбец производителя к Вашей таблице механизмов. Это - атрибут, что Вы знаете, что все механизмы будут иметь (т.е. автомобили спонтанно не появляются собой), и путем создания этого столбцом в таблице механизма, Вы решаете проблему наличия одного и только одного производителя для каждого механизма. Этот подход относился бы к любым атрибутам, которые Вы знаете, будет совместно использован всеми механизмами. Можно затем реализовать систему меток для других атрибутов, которые не универсальны.
Так беря от Вашего примера таблица механизма была бы чем-то как:
vehicle vid vin make model
Мне нужно было решить именно эту проблему (та же общая область и все - автозапчасти). Я обнаружил, что наилучшим решением проблемы было использование Lucene / Xapian / Ferret / Sphinx или любого другого полнотекстового индексатора, который вы предпочитаете. Гораздо лучшая производительность, чем у SQL.
В наши дни я почти никогда не заканчиваю созданием веб-приложения на основе базы данных, в котором нет полнотекстового индексатора. Эта проблема и общая проблема поиска возникают слишком часто, чтобы исключить индексаторы из вашего набора инструментов.