По уникальным полям в базе

Question

Подскажите как так? Вот уникальные поля uniqueidentifier. В одной базе видел, что много таблиц с полями такого типа. А из базы "достаются" абсолютно адекватные числа и тексты. Может такое быть? Или под этими многозначными данными скрываются какие то ссылки на места где хранятся обыкновенные данные

Answer 1

А что не так? Вы для определенной колонки в таблице указываете, что в ней данные все должны быть уникальными - например чтобы нельзя было добавить 2 email-а одинаковых в одно поле.

Answer 2

Да, ссылки. Допустим у вас есть две таблицы: Книги (Название, год выпуска) и авторы (ФИО, дата рождения). Понятно, что у одного автора может быть несколько книг (обратную ситуацию опусти для простоты примера). Значит у нас должна быть связь между этими таблицами. Как ее реализовать? Очень просто, в таблицу авторы, мы вносим поле которое называется первичный ключ (ну например типа uniqueidentifier). Теперь, в таблицу книги, нам не обязательно переписывать ФИО и год рождения автора, достаточно записать только его ID. Выбрав книгу, по ID автора мы его находим и показываем пользователю.

Как то так. Но! Перед тем как вы начнете работать с базами данных, прочитайте хоть что ни будь про них.

Answer 3

Если это поле в качестве уникального идентификатора то непонятно в чём разница. Ну просто поле id (int) или такое длинное из 16 цифр и чисел. насколько я знаю чем длиннее поле тем, теоретически, запрос должен дольше работать.  Про id понятно. У меня вопрос был в другом. Переиначу не про другие таблицы а про новую. Вот например. Создам базу данных. В ней две таблицы. В каждой таблице id поле и по одному полю uniqueidentifier. Больше нет ничего. Никаких данных типа nvarchar = "Петров", "Иванов", "Сидоров" нет. Всё таки придётся коснуться того примера. Кроме базы там есть ещё файлы xls. Дак то ли используются id в виде uniqueidentifier и данные по этому id считываются из excel, но тогда вопрос почему не создать просто поле id (int) с неповторяющимися значениями. и по этим id искать пусть даже в Excel. Зачем именно поле uniqueidentifier

Answer 4

Если это поле в качестве уникального идентификатора то непонятно в чём разница. Ну просто поле id (int) или такое длинное из 16 цифр и чисел. насколько я знаю чем длиннее поле тем, теоретически, запрос должен дольше работать.  Про id понятно. У меня вопрос был в другом. Переиначу не про другие таблицы а про новую. Вот например. Создам базу данных. В ней две таблицы. В каждой таблице id поле и по одному полю uniqueidentifier. Больше нет ничего. Никаких данных типа nvarchar = "Петров", "Иванов", "Сидоров" нет. Всё таки придётся коснуться того примера. Кроме базы там есть ещё файлы xls. Дак то ли используются id в виде uniqueidentifier и данные по этому id считываются из excel, но тогда вопрос почему не создать просто поле id (int) с неповторяющимися значениями. и по этим id искать пусть даже в Excel. Зачем именно поле uniqueidentifier

e int ограничение на кол-во значений, но в целом всё зависит от задачи...возможно в вашем случае достаточно инта

---

http://www.t-sql.ru

Answer 5

Зачем именно поле uniqueidentifier

Часто это бывает издержками дизайна системы. Иногда оправданными. Иногда нет. У некоторых разработчиков есть любовь к гуидам, как красивой концепции.

Answer 6

Глобальное преимущество uniqueidentifier в том, что если вам придется синхронизировать две базы, то вы объекты из одной базы можете переносить в другую с их Id. Если у вас в качестве первичного ключа int, то при переносе записи со значением ключа 1 в другую базу, там это Id уже будет занят.

Answer 7

Это локальное преимущество. Основные проблемы в синхронизации возникают с разделяемыми натуральными ресурсами(остатки денег и товаров, нумераторы и т.п), с чем никакая система создания ключей помочь не в состоянии.

Answer 8

Это локальное преимущество. Основные проблемы в синхронизации возникают с разделяемыми натуральными ресурсами(остатки денег и товаров, нумераторы и т.п), с чем никакая система создания ключей помочь не в состоянии.

Хм, можно конкретный пример вашей задачи, я что то не понял. А если у вас идет не конвертация, а именно синхронизация двух и более баз, то с GUID вы эту задачу будете решать легко и просто, а с int вам понадобиться еще одна база для хранения правил синхронизации.

Answer 9

то с GUID вы эту задачу будете решать легко и просто, а с int вам понадобиться еще одна база для хранения правил синхронизации.

Это про что? Это про то когда в таблице одной записи может соответствовать несколько записей из второй таблицы, а во второй может несколько записей в первой? Т.е. про авторов одному автору может соответствовать несколько книг, но в том же время в одной книге может быть несколько авторов из первой таблицы авторов?

Можно не создавать третью таблицу для их синхронизации, а как это можно с помощью GUID решить? Есть у Вас схема такой базы и схема таблиц?

Answer 10

то с GUID вы эту задачу будете решать легко и просто, а с int вам понадобиться еще одна база для хранения правил синхронизации.

Это про что? Это про то когда в таблице одной записи может соответствовать несколько записей из второй таблицы, а во второй может несколько записей в первой? Т.е. про авторов одному автору может соответствовать несколько книг, но в том же время в одной книге может быть несколько авторов из первой таблицы авторов?

Можно не создавать третью таблицу для их синхронизации, а как это можно с помощью GUID решить? Есть у Вас схема такой базы и схема таблиц?

Не, это мы про другое немного говорили. Для рассматриваемого случая с один автор у него много книг. Схема будет выглядеть вот так:

Видите, у нас в обоих таблицах есть поле номер автора? Давайте их заполним:

Как легко увидеть, Книгу 4 написал Иванов 1950 года рождения, а Книгу 5 - Иванов, но 1970 года рождения. Идея понятна?

А что там использовать int или uniqueidentifier (он же GUID) зависит от того, для чего база данных будет использоваться. Если она будет взаимодействовать с внешними БД, лучше GUID, если нет, то int. Ну а если вы только начинаете знакомится с базами данных, то берите int и не забивайте себе этими глупостями голову...

Answer 11

Мне сейчас хватает smallint, тут аж 32000 строк. Мне их хватает за все глаза. Я подумал, что если через GUID можно как то обойтись без третей таблицы - было бы здорово. :)

Кстати у меня однажды было так. Я подключил базу. Сделал сущности и при одинаковых именах полей (Номер автора) выползла ошибка. Потом я заменил название одного из полей и всё стало "Ок". После этого я одинаковые имена полей не делаю добавляю первые символы имени таблицы. :)

Answer 12

Вы просто не внимательно прочитали сообщение об ошибке. Вам сказали не то, что "нельзя повторяющиеся имена", а то, что "есть в разных таблицах одинаковые имена, не пойму о чем разговор". Для примера авторов-книг запрос должен выглядеть вот так:

select * from Автор inner join Книга on Автор.[Номер автора] = Книга.[Номер автора]

Эх, глядя на ваше рвение, у меня такая жалость возникает, что вы не учились у меня, чтобы я мог этому хоть чуть системности придать )) Помните в моем первом посте про почитать про базы данных? Ну, пожалуйста, почитайте ))

Answer 13

А как я жалею, что не учился на программиста ...… :( Очень интересное занятие. :) Вот системности то и не хватает согласен.