Що таке підходящий глобальний / універсальний унікальний ідентифікатор для бази даних PostGIS?


12

Я читав, що використання OID в якості основного ключа в postgreSQL / PostGIS db є поганою практикою, оскільки є випадки, коли їх можна скинути. Звучить логічно, але тоді яка підходяща альтернатива? Я вважаю, що є можливість використовувати UUID "Універсальний унікальний ідентифікатор", але велике значення тексту та цифр, яке випливає, є жахливим.

Просто трохи більше підстав для моєї ситуації. У мене всі просторові таблиці створені з полем під назвою "gid", яке є первинним ключем для цієї таблиці та унікальним лише для цієї таблиці. Зараз у мене виникла проблема, тому що я хочу пов’язати свої просторові таблиці (усі з полем "gid", починаючи з 1 і збільшуючи) до однієї великої таблиці з відповідною інформацією. Очевидно, що для моїх стосунків для роботи всі мої просторові особливості потребують унікального ідентифікатора, який відрізняє їх один від одного.

ВИДАЛЕНО Додано це зображення відповідно до коментаря Петерса. Пітер, це ідея, яку я маю в своєму голові, це може бути не найкращим способом піти про це, інакше це не може бути хороший дизайн db. Мене цікавить, що ти думаєш.

Концептуальна схема

Якісь поради?


2
"Я прочитав" ... ви могли б надати посилання?
Кірк Куйкендалл

1
Ось один із багатьох postgresql.org/docs/8.4/static/ddl-system-column.html внизу сторінки, в якому зазначається, що вважати, що вони унікальні, погана практика. Також у цьому наступному посиланні bytes.com/topic/postgresql/answers/423281-oid-not-oid відповідь на оригінальну публікацію згадується, що OID застаріли для таблиць користувачів.
Андо

1
Чи можете ви додати ще кілька конкретних деталей того, яку схему ви намагаєтеся створити. Мені не зрозуміло, що вам обов'язково потрібен глобальний унікальний ідентифікатор, якщо ви трохи зміните відносини зовнішніх ключів, наприклад.
Пітер Ейзентрав

1
I believe there is an option to use a "Universal Unique Identifer" UUID, but the large text and number value that spits out is horrible. Чому важливо, як виглядає унікальний ідентифікатор?
nmtoken

"... але велике значення тексту та цифр, яке випливає, жахливе". Ні це не так. Це довго, як це потрібно для будь-якого глобального унікального ідентифікаційного номера .
jpmc26

Відповіді:


5

Я хотів би створити окремі таблиці посередника buildings_attach, parcels_attachі т.д. Тоді вам не потрібен глобальний ідентифікатор.


Привіт Пітер, дякую за відповідь. Нарешті мені вдалося зв’язатися з нашою DBA (вона базується в іншому офісі), вона запропонувала те саме рішення, що і ви. Я радий пройти цей маршрут, оскільки я точно не є особою БД (це могло бути очевидно з моєї креслення схеми?!?), Але це справді найкраще рішення? Що станеться, якщо вкладений файл був відповідним як для функції посилки, так і для функції будівлі? У моїй вище діаграмі мені потрібно було б лише ввести деталі вкладеного файлу лише один раз, де в якості рішення DBA запропонував би мені зробити це двічі у двох різних таблицях.
Андо

1
Так, але це два окремих фрагменти інформації, тож нормально вводити їх у двох окремих місцях. Це лише спосіб розробки реляційної бази даних.
Пітер Ейзентрав

Дякую за допомогу Петро, ​​я вдячний за уточнення! Я піду по тому маршруту. Ура
Андо,

9

Два рішення:

1) Створіть одну послідовність і змусьте всі таблиці використовувати цю послідовність, це можна зробити з самого початку, або ви можете створити стовпчик ідентифікаторів та оновити таблиці зараз.

Для створення послідовності:

CREATE SEQUENCE universal_sequence;

Потім таблиця:

CREATE TABLE (
colname integer NOT NULL DEFAULT nextval('universal_sequence'));

Щоб оновити існуюче поле ідентифікатора таблиці новими ідентифікаторами (зробіть це для всіх таблиць, для яких потрібно дотримуватися тієї ж послідовності):

UPDATE table1
SET id=nextval('universal_sequence'));

2) Інше рішення: Створіть тимчасову послідовність, і вони виконують запит, створюючи новий стовпчик ідентифікатора.

Більше тут: http://www.postgresql.org/docs/8.4/static/sql-createsequence.html


4

Найкращий варіант - UUID або GUID. Вони побудовані з цієї причини, унікальні в усьому світі, незалежно від того, на якому столі. Потворний? Так, але вони найкращі для цієї ситуації.

Дивіться /programming/294933/generate-unique-id-to-share-with-multiple-tables-sql-2008

Я бачив методи, коли люди використовують дані з таблиці, щоб зробити ідентифікатори, наприклад, col1 + somestring + col2, я б дійсно радів проти цього (див. Тут ). Інтелектуальні посвідчення особи - це дійсно погана ідея.


0

Привіт

Чому б вам не взяти ідентифікатор з великого столу і замість цього не помістити просторові таблиці?

Якщо один рядок в одній з просторових таблиць стосується кількох рядків у великій таблиці, я бачу проблему, інакше ідентифікатора великої таблиці має бути достатньо, або я щось пропускаю.

/ Ніклас


Привіт Nicklas, я не можу так зробити, тому що одна з моїх просторових особливостей може стосуватися 1 або більше записів у більшій таблиці
Ando
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.