2013-09-19 3 views
1

Я хорошо знаком с СУБД MySQL. Мне интересно узнать лучший способ разработки более сложной реляционной базы данных . Например, Допустим, у меня есть таблица «users» с значением Auto Increment, которое является «Первичным ключом». Используя этот «PK» как «Foreign Key», я могу создать таблицу под названием «user_details», где я могу хранить все конфиденциальные данные пользователей.Лучший способ создания базы данных в MySql

Да, это хороший способ сделать это. Но я хотел знать, есть ли какой-нибудь сложный способ сделать это. Потому что, если любое тело в localhost получает доступ к базе данных, они могут легко получить данные «user_details» на основе пользователей «ПК».

Кроме того, является ли хорошей идеей использовать уникальные коды, созданные приложением, как «PK» и «FK» в базе данных или значение Auto Increment в базе данных более чем достаточно?

+0

Это немного пахнет проблемой XY. Если вы беспокоитесь о том, что люди получают доступ, то либо защищаете сервер/не предоставляете «никому» доступ к базе данных (разрешаете только определенные процессы, работающие как определенный пользовательский доступ), либо шифруете ваши данные и не предоставляете пользователям ключ. –

+0

@lc. Да, мы можем построить жесткую защиту вокруг базы данных. Даже на секунду я получил представление о шифровании данных. Позже я подумал, что это может вызвать некоторые проблемы с производительностью. Но мне интересно узнать, как создаются огромные реляционные базы данных? На основе самих значений «auto increment»? Если у вас есть идея, поделитесь своими знаниями :-) – sravis

ответ

0

Это очень неопределенные вопросы, поэтому я просто перечислю несколько моментов:

  • Ваша модель данных не должны быть обеспокоены безопасностью сервера. Постройте свою модель данных точно для своего приложения и заблокируйте доступ к db и таблицам как можно больше. Это отдельные проблемы.
  • Использовать шифрование для данных, которые могут знать только конечные пользователи. Например, пароли получают одностороннее шифрование.
  • Автоматический прирост MySQL достаточен для большинства случаев использования. Единственный раз, когда я иногда имею идентификаторы генерации приложения, - это multi-master replicated databases, где мне нужно больше централизованного управления или иметь уникальные требования. Это не всегда необходимо, так как вы можете установить начальный номер автоинкремента отдельно для каждого сервера и не беспокоиться о том, что серверы генерируют конфликтующие идентификаторы. Иногда возникает недостаток производительности для генерации ваших собственных идентификаторов, например. генерация GUID занимает больше времени, чем приращение целого числа.
Смежные вопросы