русский
Germany.ru → Foren → Архив Досок→ Programmierung

Как лучше хранить GUID в базе (тип данных)?

1748  1 2 3 4 alle
AlexNek патриот27.04.23 21:57
AlexNek
NEW 27.04.23 21:57 

GUID как PK, база Postgresql, для Oracle тоже интересно. В связке с EF.

Что скажете?

MS в своих примерах любит строки. Но что то многим это не нравится.

#1 
alex445 коренной житель27.04.23 23:05
NEW 27.04.23 23:05 
in Antwort AlexNek 27.04.23 21:57

Как дефолтно хранится, так и храню. Даже вопросом не задавался, как оно там. Там большие дяди сверху есть с большими зарплатами, вот пусть за меня и думают. А как начну семь знаков за работу получать, так тоже думать об этом начну. Как-то так. )))

#2 
AlexNek патриот27.04.23 23:09
AlexNek
NEW 27.04.23 23:09 
in Antwort alex445 27.04.23 23:05
Как дефолтно хранится, так и храню

А какой именно тип в базе? База ПГ?


А как начну семь знаков за работу получать, так тоже думать об этом начну

Что то мне кажется тогда уже будет поздно смущ

Вообще то никогда не имел связи между зарплатой и типом раздумий.

#3 
alex445 коренной житель28.04.23 00:47
NEW 28.04.23 00:47 
in Antwort AlexNek 27.04.23 23:09, Zuletzt geändert 28.04.23 00:48 (alex445)
А какой именно тип в базе? База ПГ?

Не знаю, что за "ПГ", но тип вроде такой и есть - GUID.


Вообще то никогда не имел связи между зарплатой и типом раздумий.

Да ладно? ))


Что то мне кажется тогда уже будет поздно

Утром деньги, вечером стулья. Вечером деньги, утром стулья. Но деньги вперёд!

#4 
MrSanders коренной житель28.04.23 14:40
NEW 28.04.23 14:40 
in Antwort AlexNek 27.04.23 21:57
GUID как PK, база Postgresql, для Oracle тоже интересно. В связке с EF.

Мнэ... Let me google it for you, понимаешь. https://www.postgresql.org/docs/current/datatype-uuid.html Вот только про связку с EF ничего сказать не могу.

#5 
Murr патриот28.04.23 15:29
Murr
NEW 28.04.23 15:29 
in Antwort AlexNek 27.04.23 21:57

Что скажете?

------

А зачем?

В смысле - там изначально не дается гарантии на уникальность...


Если не хватает размера ключа - вешай триггер на вставку и делай хоть 256+ байт ключ...

Ну или выполняй компрессию базы - через Аксесс делалось на раз...

#6 
AlexNek патриот28.04.23 21:03
AlexNek
NEW 28.04.23 21:03 
in Antwort MrSanders 28.04.23 14:40
Let me google it for you

но там нет сравнения различных способов смущ

Это первое, что интересовало.

Второе, что делает EF по умолчанию. Это я уже знаю - оракле: raw, постгрес: uuid

И третье, как как сделать преобразование базы оракле в постгресс с наименьшими затратами если "там есть" Guid.

Не забыть и про изменения в софте. Желательно никаких.

#7 
AlexNek патриот28.04.23 21:07
AlexNek
NEW 28.04.23 21:07 
in Antwort Murr 28.04.23 15:29, Zuletzt geändert 28.04.23 21:18 (AlexNek)
там изначально не дается гарантии на уникальность

"the chances of generating a duplicate GUID : 1 in 2^128;"

пока хватает, да и так уже сделано.


Если не хватает размера ключа

дело разве в этом было, что так сделали или делают?

#8 
Murr патриот28.04.23 23:52
Murr
NEW 28.04.23 23:52 
in Antwort AlexNek 28.04.23 21:07

дело разве в этом было

-----

Так никакого другого резона, кроме непомерной глупости, в использовании ГУИД в качестве ПК Я не знаю...


chances

------

Ну тут или шансы, или гарантии...

Повторюсь - для ГУИДов нет гарантии не повторения...

#9 
MrSanders коренной житель29.04.23 00:06
NEW 29.04.23 00:06 
in Antwort AlexNek 28.04.23 21:03
но там нет сравнения различных способов смущ

Это первое, что интересовало.

Так тебе шашечки или ехать?

Определись какие способы сравнивать собираешься.

Надеюсь, достаточно очевидно что на хранение 128-и битного поля бд потратит туро меньше места чем на строку.

#10 
alex445 коренной житель29.04.23 09:03
NEW 29.04.23 09:03 
in Antwort AlexNek 28.04.23 21:03, Zuletzt geändert 29.04.23 09:04 (alex445)
Не забыть и про изменения в софте. Желательно никаких.

В том же EF и подобных ORM должна быть как минимум перегенерина прослойка доступа к БД. А сами вызовы методов прослойки вроде и не меняются.


И третье, как как сделать преобразование базы оракле в постгресс с наименьшими затратами если "там есть" Guid.

Есть какие-то другие преобразования, кроме копирования данных из таблиц с вызовом newguid, newid (или подобного) для каждой новой строки? Неважно, гуиды это или обычный интегер.

Новая БД - новые идентификаторы. Только остальные данные можно полностью скопировать.

#11 
AlexNek патриот29.04.23 10:58
AlexNek
NEW 29.04.23 10:58 
in Antwort Murr 28.04.23 23:52
кроме непомерной глупости

Это не аргументы, всегда есть плюсы и минусы.


для ГУИДов нет гарантии не повторения

А отчего это должно волновать, с подобной вероятностью, в данном конкретном случае?

А даже если и будет получен не уникальный ид, какой катастрофой это будет нам грозить?

#12 
AlexNek патриот29.04.23 11:10
AlexNek
NEW 29.04.23 11:10 
in Antwort MrSanders 29.04.23 00:06
Так тебе шашечки или ехать?

Хотелось бы найти критерии выбора для каждого случая.

Пока есть две вроде 2 группы: строки и цифровая форма.


то на хранение 128-и битного поля бд потратит меньше места чем на строку

Скажем так - недостаток 1, и во всех ли случаях нам это будет интересно?

Какие еще есть?


Из достоинств, как кажется:

  • 100% переносимость
  • Минимум конвертаций, если пользуем json
  • Что вижу то и "пою". Блин, сейчас с ораклом просто катастрофа. При отладке видишь одно, в при просмотре базы совсем другое.
#13 
AlexNek патриот29.04.23 11:13
AlexNek
NEW 29.04.23 11:13 
in Antwort alex445 29.04.23 09:03
А сами вызовы методов прослойки вроде и не меняются

не меняются. А если народ любит code first?


Новая БД - новые идентификаторы. Только остальные данные можно полностью скопировать.

От подобных заяв волосы дыбом встают шок

#14 
Murr патриот29.04.23 12:19
Murr
NEW 29.04.23 12:19 
in Antwort AlexNek 29.04.23 10:58

А отчего это должно волновать

------

Я вот не припомню, чтобы в каком-нибудь софте случалось видеть обработку ошибки уникальности первичного ключа...

Судя по вопросу - ключи генерятся не на сервере, а клиентами - т.е. там вообще бардак гарантируется...


какой катастрофой это будет нам грозить?

-----

А что будет результатом выборки при наличии двух и более одинаковых ПК?

А какая именно будет первой?

#15 
AlexNek патриот29.04.23 14:23
AlexNek
NEW 29.04.23 14:23 
in Antwort Murr 29.04.23 12:19

а я вот не припомню, чтобы PK не имел "атрибута" уникальности смущ

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

#16 
Murr патриот29.04.23 14:30
Murr
NEW 29.04.23 14:30 
in Antwort AlexNek 29.04.23 14:23

а я вот не припомню

------

https://it.wikireading.ru/20048


Хотя да, исключения могут быть

-----

Именно так...

#17 
alex445 коренной житель29.04.23 16:36
29.04.23 16:36 
in Antwort alex445 29.04.23 09:03
В том же EF и подобных ORM должна быть как минимум перегенерина прослойка доступа к БД. А сами вызовы методов прослойки вроде и не меняются.

Поэтому, кстати, и не нужна эта самописная устаревшая херота типа "repository pattern". Максимум, если там какая-то лютая кастомная транзакция с задействованием кучи сущностей - ну пишешь её в отдельную функцию.

#18 
alex445 коренной житель29.04.23 16:39
NEW 29.04.23 16:39 
in Antwort AlexNek 29.04.23 11:13, Zuletzt geändert 29.04.23 16:41 (alex445)
А сами вызовы методов прослойки вроде и не меняются
не меняются. А если народ любит code first?

А это тут причём? Коде фёрст это описание модели, а функционал вы берёте от изкоробочного базового класса с поддержкой EF интерфейсов типа IQueryable, если мне не изменяет память.


Новая БД - новые идентификаторы. Только остальные данные можно полностью скопировать.
От подобных заяв волосы дыбом встают шок

Приведите заявы получше. Я не эксперт - я бы тупо скопировал данные из таблиц с новой генерацией ключей. Вы бы ключи тоже скопировали? А там есть возможность выбирать, будут ключи копироваться или генериться? Как механизм БД распознает, как генерить следующие ключи после вставки кучи готовых? Когда БД сама генерит от начала и до конца, то ей норм, а когда всякие вмешиваются в этот процесс в погоне за призрачными оптимизациями, то могут вознинуть сложности.

#19 
AlexNek патриот29.04.23 23:14
AlexNek
NEW 29.04.23 23:14 
in Antwort Murr 29.04.23 14:30, Zuletzt geändert 29.04.23 23:16 (AlexNek)

На вот попробуй 

CREATE TABLE [dbo].[AspNetRoles] ( 
  [Id] NVARCHAR(128) NOT NULL,
  [Name] NVARCHAR(256) NULL,
  [NormalizedName] NVARCHAR(256) NULL,
  [ConcurrencyStamp] NVARCHAR(MAX) NULL,
  CONSTRAINT [PK_AspNetRoles] PRIMARY KEY ([Id])
);
CREATE UNIQUE INDEX [RoleNameIndex] 
ON [dbo].[AspNetRoles] (
  [NormalizedName] ASC
);
INSERT INTO [dbo].[AspNetRoles] ([Id], [Name], [NormalizedName], [ConcurrencyStamp]) VALUES 
    ('27163748-00f8-4725-8d4e-9dce62923f2c', 'TestAdmin', 'TESTADMIN', 'af32e894-1def-4665-b7be-dff048774f1a');
INSERT INTO [dbo].[AspNetRoles] ([Id], [Name], [NormalizedName], [ConcurrencyStamp]) VALUES 
    ('274e474d-a20d-48a6-ab9a-f260a88fec43', 'TestStudents', 'TESTSTUDENTS', 'e8d8fa37-89b5-4f9d-bdc4-476111593ce9');
INSERT INTO [dbo].[AspNetRoles] ([Id], [Name], [NormalizedName], [ConcurrencyStamp]) VALUES 
    ('274e474d-a20d-48a6-ab9a-f260a88fec43','abs','abs','e8d8fa37-89b5-4f9d-bdc4-476111593ce8');

[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Violation of PRIMARY KEY constraint 'PK_AspNetRoles'. Cannot insert duplicate key in object 'dbo.AspNetRoles'. The duplicate key value is (274e474d-a20d-48a6-ab9a-f260a88fec43).

#20 
1 2 3 4 alle