Linux: Не работает звук в Linux из коробки. Linux ещё не готов к десктопу.
Windows: Не работает dns c openvpn? Не работает гибридная графика на ноуте? Чтобы запустить virtual box нужно отключить хипер-ви? А если не заработает нужно вбить пару комманд с форума? Windows нормальная десктопная ос.
Mac: звук работает из коробки. Все что не работает из коробки - не нужно!
Для организаторов нет разницы: работает эта схема или нет. Призовой фонд распределяется в любом случае. Да и не "схема" это вовсе.
Организаторы были в курсе пиковых продаж перед переливом.
А отмена лотереи и ограничения по сумме продаж — это скорее заслуга локальных sjw. С их точки зрения такой заработок "эта ничеснаа".
Запрет доступа к собственным разработкам — ситуация, конечно, абсурдная, но где здесь про "отжать бизнес" или права собственности? Компания как была его, так и останется со всеми активами.
Нет понятия ID? ОК
Как тогда называется то, что идентифицирует кортеж в случае если нет набора атрибутов уникально и однозначно идентифицирующих кортеж? https://en.wikipedia.org/wiki/Surrogate_key
Для высокнагруженных или многопользовательских систем вычисление ID выливается в неприемлемые временные потери производительности.
Я кажется довольно ясно описал сравнение производительности разных подходов. Ну если вы придираетесь к "одному такту" — хорошо. 10 тактов или 20 тактов или хотите — 30 тактов со всеми мьютексами. Это все равно на порядок (а скорей всего на два) меньше вычисления хэша и индекса для натурально ключа из двух маленьких строк.
Если вы такой опытный — подскажите:
Как людям хранить банковские транзакции в таблице. Все "исходные" натуральные атрибуты могут дублироваться даже время создания.
Какой ключ использовать?
В "классической теории реляционной БД" нет понятия "номер строки". Понятие ID (identifier) там есть. Это атрибут (именно атрибут объекта/кортежа) или набор атрибутов уникальный в рамках таблицы или набора данных.
Суррогатный ID — искусственно введенный атрибут объекта/кортежа, если объект изначально не имеет идентификатора простого либо составного.
Только Identifier может быть использован в качестве ключа:
Ключ отношения — это подсхема исходной схемы отношения, состоящая из одного или нескольких атрибутов, для которых декларируется условие уникальности значений в кортежах отношений.
Что до номера строки — это функция субд которая предоставляет (а не заставляет) возможность автоматического создания значения некого атрибута введенного в качестве суррогатного ключа (иногда даже не суррогатного).
var object1 = new SomeObject(null, "name", "value");
var object2 = new SomeObject(null, "name", "value");
Это не является вставкой за раз одной и той же записи.
Я так полагаю — там где указан null должен быть атрибут ID записи.
В контексте использования ORM Hibernate эта запись означает следующее:
"Моя изначальная структура данных не имеет атрибутов позволяющих использовать их как идентификатор (ID, identifier) и соответственно, нет возможности составить отношение т.к. нельзя определить PK. Поэтому я декларирую искусственный атрибут ID/identifier/ИНН.
И создавая запись с использованием Hibernate, я следую документации которая указывает опустить идентификационный атрибут, и тогда Hibernate установит его сам с учетом конфигурации.
Hibernate может как использовать счетчик (sequence) в бд, так и заданные мной генераторы для формирования атрибута."
Но ничего не мешает работать вот так
var object1 = new SomeObject({{fucking_line_number}}, "name", "value");
т.е. напрямую указывать ID.
"Генерация уникального ID — неизбежные временные потери."
Да — неизбежные. Существенные? а вот это уже спорно.
Как их избежать — используйте sequence. Как их уменьшить — используйте суррогатный ключ простого типа.
Генерация ключа sequence — один машинный такт. Буквально.
При использовании составного или естественного ключа помимо генерации всегда идет проверка уникальности. А это вычисление хэша и поиск по индексу.
В этом плане хорош UUID: несмотря на свою кажущуюся громоздкость это всего лишь 128-битное число.
ID — мусор, в БД построенной по этому принципу, обязательно есть таблицы, где ID вообще никогда не используются в условии WHERE или прочих условиях объединения таблиц.
Если в некоторых таблицах есть PK (атрибут гарантирующий уникальность через "номер строки"), но он никогда не используется, значит только то, что допущены серьезные ошибки при проектировании схемы данных или формулировании требований к системе. Не стоит путать причину и следствия.
"ID не используется в части таблиц по своему прямому назначению -> значит ID "мусор""
"Плохой дизайн схемы данных -> ID не используется в части таблиц по своему прямому назначению"
Заметьте разницу
Да же в вашем примере ID не ограничивает эксплуатационные характеристики.
Проблемы описанные в примере давно решаются, например с помощью шардинга. Хотя он здесь лишний вероятно.
ресурсоемкие алгоритмы генерации значений
Специально придуманы нересурсоемкие алгоритмы, например UUID который вообще не требует общего разделяемого ресурса для координации значений.
Плюс надо осознавать особенности системы, например отношение чтения-записи.
sequence в бд: самое быстрое создание (даже с учетом конкурентного доступа) самая быстрая проверка уникальности и чтения т.к. не происходит расчета хэшей и индекса.
UUID: Быстрая генерация и быстрая вставка за счет отсутствия индекса (не везде правда) т.к. повторюсь — это всего лишь 128-битное число.
Естественный идентификатор — очень повезет если это заведомо уникальный атрибут, который можно привести к числу, тогда получаем почти первый вариант.
Если не повезло и имеем составной ключ из двух строковых колонок по 50 символов, то получаем расчет хэша на массиве до 100 байт с проверкой в индексе и обновление индекса, что является гораздо более ресурсоемкой операцией.
во всех БД с использованием ID вам нужно присоединять дополнительные таблицы, чтобы получить в выборке ID, хотя требуемый результат Вы уже имеете без этого ID
Если вы имеете требуемый результат (кортеж) и нужно "присоединить" еще одну таблицу с ID этого кортежа (ID кортежа не в таблице с кортежем — что???), то у меня для вас плохие новости...
"и если программист перепутал поля таблиц" — а если программист также перепутал поля составного ключа в объединении? Это другое?
И последнее — мы с вами не коллеги и, надеюсь, никогда не будем.
Знаете, ваши рассуждения похожи выводы удивленного "джуна", который начитался про естественные ключи и решил, что это "серебряная пуля" и лекарство от всех бед.
Вы замечаете действительно очевидные вещи, но делаете неверные выводы.
Удачи вам в хранении, например, банковских транзакций с составным PK. И терпения вашим коллегам.
"ID — это номер строки и какой либо другой характеристики записи он не несет."
Вы вдолбили себе в голову бредовую идею и даже не пытаетесь понять суть того, что говорят другие. Вы пытаетесь навязать свои "откровения". Высказываете "революцинные" утверждения и ни разу не привели ни одного обоснования своих "идей".
От того что вы будете повторять их как мантры фатами они не станут.
"И если у Вас не "болит голова" из-за ID, то это только потому, что Вы перекладываете эту "боль" на других коллег..."
Вы столкнулись с кривым дизайном? Испытали боль?
Но не нужно проецировать это на других. Не мешайте в кучу нарушения целостности и тип ключа и способ их формирования. И уж, пожалуйста, не стоит обвинять меня в том что я перекладываю "боль" на своих коллег, только потому, что не хочу отказываться от суррогатных ключей.
У вас есть хорошая библиотека по реляционным бд? Замечательно, перечитайте ее еще раз. И относитесь спокойно к числам в качестве ID.
Это может быть грубо, но вы меня утомили.
Вы привели в пример результат неграмотности архитектора/лида/лица ответственного за архитектуру. Банальная проблема с которой сталкиваются студенты в на первых порах проектирования систем. Это как раз и возникает из-за того, что люди упорно считают суррогатный ID «номером строки в таблице».
«Не используйте...», «у Вас исчезнут все „головные боли“...»
Еще раз: у Нас нет головных болей из-за использования идентификаторов.
Вы приведите пример схемы данных из вашей системы где «ID в таблицах нет вообще». Так было бы гораздо проще Вас понять.
Примеры «как не нужно» — это, конечно, хорошо. Но где примеры «как нужно»?
Ваша концепция звучит хорошо — слишком хорошо. Но где примеры?
Плюс все Ваше рассуждение основано на довольно сомнительных утверждениях.
1. «Как можно использовать в реляционных моделях суррогатный ключ ID записи, который по сути является номер строки в таблице?»
2. Для «борьбы» с этой проблемой вам приходиться самим реализовывать тот или иной собственный «реляционный» механизм. Неважно какой, важно, что приходится!
3. Вы говорите, что можно вычислять ID в приложении, но тогда сразу ставится крест на многоузловой эксплуатации приложения…
4. для достижения уникальности записи — «пишем» лишний код
и так далее по всем пунктам.
…
И т.д.
Думаю вам стоит попробовать заменить ID в рассуждениях на «name in namespace».
И «вам приходится» на «мне приходится» в комментариях…
Ничего из описанного выше не значит, что для достижения уникальности id или записи нужно писать лишний код.
Хотя если Вам очень хочется — пишите на здоровье.
Linux: Не работает звук в Linux из коробки. Linux ещё не готов к десктопу.
Windows: Не работает dns c openvpn? Не работает гибридная графика на ноуте? Чтобы запустить virtual box нужно отключить хипер-ви? А если не заработает нужно вбить пару комманд с форума? Windows нормальная десктопная ос.
Mac: звук работает из коробки. Все что не работает из коробки - не нужно!
Не могу понять: "Не хочу знать правду" - это не правильно или просто вид "не хочу знать правды" допустим и имеет свое название?
Для организаторов нет разницы: работает эта схема или нет. Призовой фонд распределяется в любом случае. Да и не "схема" это вовсе.
Организаторы были в курсе пиковых продаж перед переливом.
А отмена лотереи и ограничения по сумме продаж — это скорее заслуга локальных sjw. С их точки зрения такой заработок "эта ничеснаа".
Запрет доступа к собственным разработкам — ситуация, конечно, абсурдная, но где здесь про "отжать бизнес" или права собственности? Компания как была его, так и останется со всеми активами.
Не смотря на мое плохое воспитание, я:
Нет понятия ID? ОК
Как тогда называется то, что идентифицирует кортеж в случае если нет набора атрибутов уникально и однозначно идентифицирующих кортеж?
https://en.wikipedia.org/wiki/Surrogate_key
Я кажется довольно ясно описал сравнение производительности разных подходов. Ну если вы придираетесь к "одному такту" — хорошо. 10 тактов или 20 тактов или хотите — 30 тактов со всеми мьютексами. Это все равно на порядок (а скорей всего на два) меньше вычисления хэша и индекса для натурально ключа из двух маленьких строк.
Если вы такой опытный — подскажите:
Как людям хранить банковские транзакции в таблице. Все "исходные" натуральные атрибуты могут дублироваться даже время создания.
Какой ключ использовать?
Это снова вы… Я уже даже начал скучать
В "классической теории реляционной БД" нет понятия "номер строки". Понятие ID (identifier) там есть. Это атрибут (именно атрибут объекта/кортежа) или набор атрибутов уникальный в рамках таблицы или набора данных.
Суррогатный ID — искусственно введенный атрибут объекта/кортежа, если объект изначально не имеет идентификатора простого либо составного.
Только Identifier может быть использован в качестве ключа:
Что до номера строки — это функция субд которая предоставляет (а не заставляет) возможность автоматического создания значения некого атрибута введенного в качестве суррогатного ключа (иногда даже не суррогатного).
Это не является вставкой за раз одной и той же записи.
Я так полагаю — там где указан null должен быть атрибут ID записи.
В контексте использования ORM Hibernate эта запись означает следующее:
"Моя изначальная структура данных не имеет атрибутов позволяющих использовать их как идентификатор (ID, identifier) и соответственно, нет возможности составить отношение т.к. нельзя определить PK. Поэтому я декларирую искусственный атрибут ID/identifier/ИНН.
И создавая запись с использованием Hibernate, я следую документации которая указывает опустить идентификационный атрибут, и тогда Hibernate установит его сам с учетом конфигурации.
Hibernate может как использовать счетчик (sequence) в бд, так и заданные мной генераторы для формирования атрибута."
Но ничего не мешает работать вот так
т.е. напрямую указывать ID.
"Генерация уникального ID — неизбежные временные потери."
Да — неизбежные. Существенные? а вот это уже спорно.
Как их избежать — используйте sequence. Как их уменьшить — используйте суррогатный ключ простого типа.
Генерация ключа sequence — один машинный такт. Буквально.
При использовании составного или естественного ключа помимо генерации всегда идет проверка уникальности. А это вычисление хэша и поиск по индексу.
В этом плане хорош UUID: несмотря на свою кажущуюся громоздкость это всего лишь 128-битное число.
Если в некоторых таблицах есть PK (атрибут гарантирующий уникальность через "номер строки"), но он никогда не используется, значит только то, что допущены серьезные ошибки при проектировании схемы данных или формулировании требований к системе. Не стоит путать причину и следствия.
"ID не используется в части таблиц по своему прямому назначению -> значит ID "мусор""
"Плохой дизайн схемы данных -> ID не используется в части таблиц по своему прямому назначению"
Заметьте разницу
Да же в вашем примере ID не ограничивает эксплуатационные характеристики.
Проблемы описанные в примере давно решаются, например с помощью шардинга. Хотя он здесь лишний вероятно.
Специально придуманы нересурсоемкие алгоритмы, например UUID который вообще не требует общего разделяемого ресурса для координации значений.
Плюс надо осознавать особенности системы, например отношение чтения-записи.
Если не повезло и имеем составной ключ из двух строковых колонок по 50 символов, то получаем расчет хэша на массиве до 100 байт с проверкой в индексе и обновление индекса, что является гораздо более ресурсоемкой операцией.
Если вы имеете требуемый результат (кортеж) и нужно "присоединить" еще одну таблицу с ID этого кортежа (ID кортежа не в таблице с кортежем — что???), то у меня для вас плохие новости...
"и если программист перепутал поля таблиц" — а если программист также перепутал поля составного ключа в объединении? Это другое?
И последнее — мы с вами не коллеги и, надеюсь, никогда не будем.
Знаете, ваши рассуждения похожи выводы удивленного "джуна", который начитался про естественные ключи и решил, что это "серебряная пуля" и лекарство от всех бед.
Вы замечаете действительно очевидные вещи, но делаете неверные выводы.
Удачи вам в хранении, например, банковских транзакций с составным PK. И терпения вашим коллегам.
Вы вдолбили себе в голову бредовую идею и даже не пытаетесь понять суть того, что говорят другие. Вы пытаетесь навязать свои "откровения". Высказываете "революцинные" утверждения и ни разу не привели ни одного обоснования своих "идей".
От того что вы будете повторять их как мантры фатами они не станут.
Вы столкнулись с кривым дизайном? Испытали боль?
Но не нужно проецировать это на других. Не мешайте в кучу нарушения целостности и тип ключа и способ их формирования. И уж, пожалуйста, не стоит обвинять меня в том что я перекладываю "боль" на своих коллег, только потому, что не хочу отказываться от суррогатных ключей.
У вас есть хорошая библиотека по реляционным бд? Замечательно, перечитайте ее еще раз. И относитесь спокойно к числам в качестве ID.
Это может быть грубо, но вы меня утомили.
«Не используйте...», «у Вас исчезнут все „головные боли“...»
Еще раз: у Нас нет головных болей из-за использования идентификаторов.
Вы приведите пример схемы данных из вашей системы где «ID в таблицах нет вообще». Так было бы гораздо проще Вас понять.
Ваша концепция звучит хорошо — слишком хорошо. Но где примеры?
Плюс все Ваше рассуждение основано на довольно сомнительных утверждениях.
1. «Как можно использовать в реляционных моделях суррогатный ключ ID записи, который по сути является номер строки в таблице?»
2. Для «борьбы» с этой проблемой вам приходиться самим реализовывать тот или иной собственный «реляционный» механизм. Неважно какой, важно, что приходится!
3. Вы говорите, что можно вычислять ID в приложении, но тогда сразу ставится крест на многоузловой эксплуатации приложения…
4. для достижения уникальности записи — «пишем» лишний код
и так далее по всем пунктам.
…
И т.д.
Думаю вам стоит попробовать заменить ID в рассуждениях на «name in namespace».
И «вам приходится» на «мне приходится» в комментариях…
Ничего из описанного выше не значит, что для достижения уникальности id или записи нужно писать лишний код.
Хотя если Вам очень хочется — пишите на здоровье.