У стовпці особи повторно заносять: коли це потрібно?

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

Одна з вимог полягала в тому, що стовпець ідентичності (який є ПК у кожній таблиці) повинен бути послідовним, оскільки це хороша практика (відповідно до слів лектора). Тобто, коли рядок таблиці видалено, PK необхідно повторно використовувати в наступних вставках. Я маю середні знання в RDBMS, ПК та стовпцях ідентичності. Як я розумію, цей стовпець ідентичності - це лише спосіб дозволити БД автоматично генерувати ПК при вставлянні рядків і більше нічого. І значення стовпця ідентичності жодним чином не має стосуватися атрибутів рядків (доки це не є природним ключем).

Ця вимога (строго послідовний стовпець ідентичності) була для мене підозрілою. Я намагався запитати викладача, що не так, якщо ідентичність не є послідовною (з прогалинами, викликаними видаленням), але отримала дуже абстрактну відповідь на кшталт "це зручно для користувачів і корисно для адміністраторів БД, які підтримують базу даних". Конкретних прикладів немає. Аргумент "зручний для користувачів" звучить нерозумно, оскільки він не має жодного значення в діловій сфері.

Тому мені цікаво, чи ці причини справжні? Я можу думати лише про один випадок, коли потрібна повторна повторна передача стовпця особи - коли простір ідентичності вичерпано. Але це більше питання дизайну, коли тип стовпця ідентичності вибрано неправильно, скажімо, простий intзамість bigintабо uniqueidentifierколи таблиця містить мільярди рядків. Припустимо, стовпець ідентичності - це кластерний індекс: чи можуть пробіли в стовпці ідентичності впливати на ефективність індексу? Можливо, є й інші реальні причини автоматичного повторного нанесення стовпця особи після кожного видалення, про який я не знаю?

Спасибі заздалегідь!

Тобто, коли рядок таблиці видалено, PK необхідно повторно використовувати в наступних вставках.

З якого Всесвіту ваш лектор ??

Це вкрай неефективно. Якщо ви спробуєте це зробити, ви зменшите свої показники ефективності в 10 разів.

Якщо вам потрібні безлічі номери з аудиторських причин, будуйте їх явно, а не безпосередньо з інструментів бази даних. І ніколи не видаляйте рядки, а позначайте їх як "видалені". Це додасть безладдя запитів, оскільки їм доведеться ігнорувати такі рядки.

У MySQL InnoDB вимагає існування унікальної PRIMARY KEYдля кожної таблиці. Але це ступінь вимоги. Ключовим може бути навіть рядок.

Прогалини - це зручність для користувачів та DBA, а не незручність.

Я можу придумати один випадок, коли безладно було б зручно - збивати групи за 100 рядів за один раз. Але є просте вирішення способу використання LIMIT 100,1.

Прогалини мають нульовий вплив на продуктивність. Це включає нечислові індекси. І не унікальні індекси. І складені індекси.

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

Розриви відбуваються з (по крайней мере): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(явне, або з - за аварії), Мульти-майстер реплікації ( в тому числі і Галера групи реплікації). Ви дійсно хочете придумати для них шляхи вирішення ?!

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

Взагалі використання вартості ідентичності слід взагалі не рекомендувати. Або значення використовується цілком внутрішньо, і в цьому випадку його фактичне значення є несуттєвим, або воно також використовується зовнішньо; в цьому випадку повторне використання значення, швидше за все, призведе до неправильної ідентифікації.

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

Вирішення таких питань може бути великим клопотом, коли компанії зливаються або купуються. Створювати такі проблеми спеціально? Не мудрий.

Повторне використання значень PK id має проблеми, і їх взагалі слід уникати.

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

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

По-третє, bigint unsignedідентифікаторів не закінчиться протягом значного часу, навіть з урахуванням надзвичайно великої швидкості вставки.

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

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

Пошкодження самого індексу ПК.

Зрозуміло, що це використовувалося MS-SQL і багато, багато років тому, але це все ще актуально. Багато років тому для компанії, в якій я працюю, хтось подумав, що було б гарною ідеєю повторно використовувати ПК у якості серверів у наших 150+ віддалених місцях після того, як вони були занадто старі, щоб їх використовувати клієнти, а потім вставити їх у шафу без вентиляції. Коли ні, тому що всі ми знаємо, що купа небажаного 10-річного комп’ютера в крихітному приміщенні з темпами 120+, що працюють на критичних базах місій, може призвести лише до хороших речей. Як 40% відмов, і я переосмислюю свій вибір кар'єри. Ми б тиражували дані назад до штаб-квартири корпорації, але частіше за все ці збої призводять до поганих ситуацій з базами даних. Однією з таких речей була база даних із пошкодженими індексами, які захоплювали б базу даних та процес реплікації. У цьому прекрасному середовищі двічі єдиним рішенням виправити реплікацію було повторно встановити індекси та потім відновити реплікацію. Ми замінили сервери пізніше, перш ніж їх повністю скинути.