MySQL Question - Как обработать несколько типов пользователей - одна таблица или несколько?
Отдайте должное ответу @ chad-m.
Вот версия Swift:
- Создать новый файл
MyNavigationController.swift
import UIKit
class MyNavigationController: UINavigationController, UINavigationControllerDelegate {
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
self.delegate = self
}
func navigationController(_ navigationController: UINavigationController, willShow viewController: UIViewController, animated: Bool) {
if viewController == self.viewControllers.first {
self.setNavigationBarHidden(true, animated: animated)
} else {
self.setNavigationBarHidden(false, animated: animated)
}
}
}
- Установить класс вашего UINavigationController в StoryBoard на MyNavigationController
Вот и все!
Разница между ответом chad-m и моим:
-
Наследуйте от UINavigationController, так что вы не будете загрязнять свой rootViewController.
-
используйте
self.viewControllers.first, а неhomeViewController, поэтому вы не будете делать это 100 раз для ваших 100 контроллеров UINavigation в 1 StoryBoard.
4 ответа
Ваши инстинкты не хотят создавать большую таблицу с большим количеством NULL. Это плохая идея с точки зрения хранения / получения / обслуживания, а также с точки зрения проверки данных (подробнее об этом позже).
Два наиболее распространенных подхода:
1) Создайте пользовательскую таблицу со всеми общими полями в нем, включая поле «userType». Затем создайте отдельную таблицу для каждого типа пользователя, содержащую дополнительные поля. У всех пользователей есть строка в таблице пользователей и одна или несколько таблиц определенных типов пользователей. Это наиболее нормализованный и самый эффективный для хранения и быстрого входа в систему. Это также позволяет вам использовать ограничения и внешние ключи, чтобы гарантировать, что вся необходимая информация для каждого типа пользователя доступна.
2) Создайте пользовательскую таблицу со всеми общими полями в ней. Назовите другую таблицу вроде UserAttributes , в которой есть поля для идентификатора пользователя, ключа и значения. Здесь могут храниться любые дополнительные метаданные для конкретного пользователя. Это имеет то преимущество, что не требует от администрации базы данных добавлять новые типы пользователей или метаданные, которые будут храниться для каждого типа пользователей. Однако он не позволяет выполнять какие-либо проверки данных на уровне БД.
Реляционная модель как таковая не поддерживает «наследование», которое могло бы помочь решить эту проблему. (хотя некоторые механизмы БД, такие как PostgreSQL, поддерживают наследование.)
Итак, я сначала хотел бы спросить себя - должны ли разные типы пользователей иметь возможность появляться в одном контексте, по крайней мере в некоторых случаях ? Если это так, то вы не можете просто скопировать и вставить «общие столбцы» в несколько таблиц (по крайней мере, не без ущерба для проверок целостности, которые вы могли бы получить в этих случаях через внешние ключи в одной таблице).
Вторая вопрос - возможно ли когда-либо пользователю занимать более одной роли? Во многих случаях это было бы необычно , но не совсем невозможным, например, служащий может также быть поставщиком или покупателем.
Если бы я не мог получить точных ответов на такие вопросы, руководствуясь иначе, я бы создал таблицу пользователей только с общими полями; и отдельные таблицы для поставщиков, сотрудников, бета-тестеров, клиентов и любых других типов и ролей, которые у меня могут быть для пользователей, каждая со своими собственными специализированными столбцами плюс внешний ключ в таблице пользователей, чтобы собрать все остальное.
Я понимаю, что нормализованные схемы сейчас вышли из моды, но они верно служили мне на протяжении десятилетий, и я испытываю к ним глубокую привязанность - я денормализирую их только тогда, когда мне нужны конкретные оптимизации, а это происходит гораздо реже, чем можно подумать! -
Одна несколько денормализация, которая, вероятно, может быть здесь полезна, - это столбец перечисления в таблице пользователей, указывающий «основной» или «единственный»
Это знаменитый вопрос нормализации.
Взгляните на эту статью или другие подобные статьи, чтобы попытаться найти ответ, который соответствует потребностям бизнеса.
You didn't say if you were using a high-level language, so I'll just give a general example with DB-like example:
Database design is hard. So, this will be a quick and simple answer.
Your question is a basic question about data relationships, and database design. Search out some basic how-to guides to help this answer. It may help to think of how your information is grouped, and link "back" to the primary set (table) from the other sets (tables).
So, users are users -- thats your table. It should contain the main, common elements (columns) of data associated with a user.
Then, this other set of information (e.g., permissions or something) is another table.
Just make sure this other table has a value (column) that points back to the user, to which it refers. You will probably want to tell your database to create an "index" between them (to improve lookup performances, etc.)
E.g., A kind of "permission" table for users:
- integer "id" <--- unique, index column, auto-increment
- integer "user_id" <--- this is which user this belongs
- ...
- Boolean "can_write" <--- example data column
- Boolean "can_read" <--- example data column
- Boolean "can_reboot_system" <--- example data column
- etc, whatever you want
So, you could "SELECT * FROM user_table WHERE first_name = 'joe' (or such) ... to get a user. In there, I'd hope you have some kind of 'id' value to identify that row.
Now, just do a 'SELECT * FROM permissions WHERE user_id = 'nnnn' (whatever that user's id is).
If a user has only 1 permission set, then you could just have that user_id without the additional "id" column.