Чи потрібні мені ідентифікатори в моїй базі даних, якщо записи можна було визначити за датою?

17

Я пишу свою першу заявку на Android і буду використовувати базу даних SQLite, тому буду намагатися максимально обмежити розмір, але я думаю, що питання стосується загального дизайну баз даних.

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

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

database

— Нієшка
джерело

SQLite завжди створюватиме цілий стовпець для rowid, якщо не вказати ціле ПК. Тому не розраховуйте на те, що стовпець "Ідентифікатор" не має бути способом економії місця.

— Кодизм

Додам, що в Android для деяких класів потрібні таблиці, щоб мати стовпець _id для роботи. Більше інформації на цю відповідь .

— bigstones

5

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

— Євген

22

IMHO, найкраще уникати використання стовпця дати як основного ключа.

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

Деякі інші моменти, які ви можете розглянути:

Ви можете подумати, що момент часу унікальний, але це, скоріше, залежить від деталізації стовпця дати. Це хвилини, секунди, мілісекунди та ін. Чи можете ви бути абсолютно впевнені, що ви ніколи не отримаєте порушення первинного ключа?

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

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

Редагувати:

Слід зазначити, що це жодним чином не вказує на те, що це неякісне дизайнерське рішення. Просто, що можуть виникнути проблеми з практичними питаннями, про які йдеться.

— Роббі Ді
джерело

минуло деякий час, відколи я написав запит SQLite, але чи не фільтрується за датами, ідентичними фільтрації за цілими числами, окрім більш деталізованого декларування обов'язкових значень?

— DougM

Це просто більш багатослівно, а також на деяких RDBMS ви отримуєте цю проблему, де елемент дня та місяця змінюється, якщо БД створено у форматі США.

— Роббі Ді

Дякую, це все хороші відповіді, але ваш досвід роботи напевно запечатав угоду.

— Nieszka

Як постскрипт до цього: Тільки сьогодні мені передали питання підтримки таблиці аудиту додатків, де вони отримують порушення первинного ключа для номера співробітника та ПК / дати доступу / часу через різницю у часі між двома клієнтськими пристроями. ..

— Роббі Ді

13

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

АЛЕ ...

... що сказано, ви можете так само використовувати його будь-коли. Маленький секрет тут полягає в тому, що SQLite вже має унікальний ідентифікатор автоматичного збільшення для кожної таблиці під назвою ROWID. Якщо ви оголосите цілочисельний стовпчик з автоматичним збільшенням у своїй таблиці як ПК, SQLite не створить новий стовпець - він буде просто псевдонімом попереднього стовпця ROWID.

У SQLite кожен рядок кожної таблиці має 64-розрядне ціле число ROWID з підписом. ROWID для кожного ряду є унікальним серед усіх рядків тієї ж таблиці.

Ви можете отримати доступ до ROWID таблиці SQLite за допомогою одного спеціального імені стовпця ROWID, ROWID або OID. За винятком випадків, коли ви оголошуєте звичайний стовпець таблиці для використання одного з цих спеціальних імен, тоді використання цього імені буде посилатися на оголошений стовпець, а не на внутрішній ROWID.

Якщо таблиця містить стовпець типу INTEGER PRIMARY KEY, то цей стовпець стає псевдонімом ROWID. Потім ви можете отримати доступ до ROWID, використовуючи будь-яке з чотирьох різних імен, оригінальні три імені, описані вище, або ім'я, вказане у стовпці INTEGER PRIMARY KEY. Усі ці імена є псевдонімами один для одного і однаково добре працюють у будь-якому контексті.

http://www.sqlite.org/autoinc.html

Отже, ви не будете економити будь-який простір, не використовуючи стовпчик ідентифікатора, оскільки отримуєте по одній таблиці, хочете ви цього чи ні!

— ГрандмайстерB
джерело

9

Використовуйте поле ідентифікатора, якщо виконується будь-яке з наведеного нижче:

Не існує природного ключа (дата не буде унікальною)
Поле дати буде часто змінюватися
Дата може бути невідома на момент вставки.
Багатокольоровий ідентифікатор перевищує три стовпці, що зробить приєднання занадто багатослівним.

Прочитайте це запитання: чи існує канонічне джерело, яке підтримує «сурогати»?

Редагувати:

Оскільки, на мій погляд, здається, що жодне з перерахованого вище не відповідає дійсності, вам не потрібно використовувати поле та ідентифікатор, але ви можете використовувати його, якщо хочете.

— Тулан Кордова
джерело

1

Стовпці ідентифікаторів +1 - це запах коду схеми, що вказує на те, що ваші дані дійсно не відповідають реляційній моделі.

— Росс Паттерсон

10

@RossPatterson Я не такий впевнений. Я можу придумати ряд випадків, коли не існує природного ключа, але дані все ще можуть відповідати реляційній моделі. Лише один випадок у верхній частині моєї голови: зберігання інформації про живих осіб. Багато ( не всі! ) Країни присвоюють унікальний ідентифікатор кожному громадянину, але це не означає, що використання цього ідентифікатора є доцільним або навіть можливим (це може бути невідомо під час створення запису, може бути не призначено або його використання може бути заборонено, наприклад, діючими нормами). Чи означає це, що дані не відповідають реляційній моделі? Я не думаю, що так.

— CVn

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

— user470365

4

Будь то вбудований (a la Oracle) або доданий як сумлінний стовпчик, вони дуже корисні. Оскільки хтось, хто опинився з обох боків огорожі (DBA та розробник), набагато простіше вивести таблицю з ідентифікатором, який ви можете гарантувати, буде унікальним.

— Роббі Ді

1

@RobbieDee Ви маєте рацію. Це поза темою.

— Тулен Кордова

2

Майте на увазі, що ви також можете змінити значення стовпця "дата" з created_atна updated_atабо будь-яку іншу зміну уздовж цих рядків, що, як я вважаю, є дуже поширеним випадком.

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

— wlk
джерело

Додавання +1_create та date_modified до таблиць дуже корисно для відстеження, коли рядки були створені та оновлені. Це варто важити золота при дослідженні проблем із оновленням сховища / сховища даних.

— Роббі Ді