Суррогат не касается логики данных. Таблица с суррогатным ключом по прежнему останется таблицей без первичного ключа. Суррогатный ключ это всего лишь технический приём который сильно облегчает работу приложения т.к. избавляет от составных ключей и делает ненужным касквдное обновление при изменении естественного ключа.
Я могу представить что инкрементный ключ делает сложной или даже бесполезной кластеризации. Но не могу представить какие ещё проблемы он несёт. Поделитесь примерами если это не секрет
Если говорить о теории реляционных баз данных то двух не различимых строк не может быть суррогат здесь не спасёт. Говоря о конкретном примере например продукт питания то давайте проследим его путь от производства до потребителя.производитель присваивает изделию номер партии на которую составляет документы о его качестве. Внутри партии коробки с овсянкой неразличимы и выступают в своём количестве. Далее партия или её часть отгружается промежуточному складу или напрямую магазину. так появляется номер накладной. После этого в магазине вы закупаете товар по чеку. И все ещё по прежнему вы можете посмотреть номер партии производителя. Хотя напимер для вас как для клиента теряется информация о номере накладной.
Потребовалось какое-то время, чтобы в реализациях SQL пропало несоответствие ключей и реляционной модели, самые ранние базы данных были заточены под низкоуровневую концепцию первичного ключа. Первичные ключи в таких базах требовались для идентификации физического расположения строки на носителях с последовательным доступом к данным. Вот как это объясняет Джо Селко:
Термин «ключ» означал ключ сортировки файла, который был нужен для выполнения любых операций обработки в последовательной файловой системе. Набор перфокарт считывался в одном и только в одном порядке; невозможно было «вернуться назад». Первые накопители на магнитных лентах имитировали такое же поведение и не позволяли выполнять двунаправленный доступ. Т.е., первоначальный Sybase SQL Server для чтения предыдущей строки требовал «перемотки» таблицы на начало.
Хотелось бы посмотреть на оригинал или периевод цитаты. Я ее не нашел в переводе популярной книги Джо Селко (который катати был противникам суррогатных ключей судя по его пекомендациям в этой книге).
Есть два момента. Действительно с 1963 года начали использовать индексный метод доступа к данным ISAM который предвосхитил современный базы данных. ФИшкой этого метода было как раз то что в индексе содержались физические адреса данных а доступ к индексу можно было органпзовать по человекопонятным цифрам (например код товара, ISBN и т.п.) Это я о первом абзаце (слова автора)
Что касается цитаты Джо Селко (я конечно надеюсь узнать о первоисточнике цитаты) Хранение индексных наборов было сдорогостоящей операцией а до изобретения НЖМД еще и медленной т.к. для поиска лента перематывалаь в разные стороны. Поэтому реляционную модель реализовывали при помощи плоских файлов и их сортировки по ключу. Это позволяло делать расчеты. Приведу пример. Есть два плоских файла остатки товара и прайс. Оба файла сортируются по коду товара и сливаются в один файл. ПАосле этого полученный файл сортируется например по материально ответсвенному лицу и получаются итоги в денежном выражение «в разрезе» как это было принято говорить материально ответсвенных лиц.
Есть несколько вопросов к автору. Где можно найти определения искуственных но не суррогантых ключей а так же внутренних ключей? Какое отношение имеет ограничение UNIQUE к ключам? (Напомню ограничение UNIQUE не нарушают повторяющиеся значения значения NULL) С моей точки зрения не совсем раскрыта тема что индекс, ключ, суррогатный ключ и ограничение — это вещи практически из разных галактик. Поясню что я имею в виду. Ключ относится к логичесой организации данных. Суррогатный ключ относится к уровню приложения. Наличие суррогатного ключа не делает базу нормализованной хотя формально первичный ключ вроде бы и есть. Индекс так это способ ускорить выборку. Кстати MySQL на каждый внешний ключ создает дополнительный индекс. А вот PostgreSQL — не создает. И многие удивляются что выборка тормозит. Нужно создавать явно увы. А ограничение это и есть ограничение отменит в случае чего добавление обновление удаление записи.
Я пытаюсь с totp но гугл мне не позволяет это сделать без телефона. Возможно если это делать с другого девайса или же если уже было раньше активировано то можно. Сейчас только телефон. Даже если это можно сделать зайдя в какой-то режим через лабиринт меню этоне меняет основного. Гугл хочет мой телефонный номер.
Картинка
Аттракцион невиланной щедрости (в смысле что он готов заплатить)
Разделено в хорошем смысле этого слова. В смысле разделения ответсвенности. Случая при котором мое описание разойдется с моей реализацией сложно представить. Поскольку в отличие от OpenAPI где специфкация — это просто документ yml/json или же программно описанная специфкация, или же код взятый из аннотаций к классам и методам, в graphql это все по-другому реализовано в единой системе. Это не избавляет от логических ошибок но во всяком случае гарантирует соответсвие описанию (и валидацию) по входящим параметрам и выходящим параметрам спецификации метода.
+ как я уже сказал фича с запросами которые гибко управляются клиентом. Что является отдельным и существенным преимуществом.
За totp не знал включу себе на одном из эккаунтов. Но это не снимает вопросов с смс. Т.к. 1 при логине предлагается защититься все же телефоном и для большинства к которому я отношу себя это смс и только и 2 если установить Аутентификатор на ios то не за требует ли он повышенного доступа? Что касается андроид то вопрос от разработчиков ОС разрешение ли вы определить свою координатузвучит риторически
Реальность такова что это правда. Поэтому прежде чем что-то юзать свободно распространяемое я смотрю на численность контрибьюторов. И анализирую вероятность того что проект будет закрыт и репозитарий удален. Как правило серьезные свободные проекты проекты не пытаются изменить правила в процессе игры (типа давайте вы подсядете на нас а потом мы включим счетчик). Есть проекты которые к сожалению закрылись. Например rethinkdb.com/blog/rethinkdb-shutdown — это тоже может произойти с каждым. Но представить что в вашем package.json или composer.json при следующем деплое половина зависимостей будет недоступна было бы катастрофой для многих проектов.
Не совсем уместный сарказм. Я как раз не призываю «усиливать» безопасность предоставлением гуглу свою координату и номер телефона (заодно и образец голоса).
Я всего лишь говорю что 2-х факторная это хорошо там где это нужно. Но не стоит отдавать больше контроля над своими личными данными (координата, голос, номер телефона) там где это не нужно.
Двухфакторная аутенфикация конкретно от гугла и хайп который они пытаются поднять это просто способ получить номер телефона и координату не только для андроидов а и для всех абсолютно. Так что я если что против такой псевдобезопасности
Для меня самого загадка кто и почему поддерживает бесплатные проекты. Не указано что статья перевод хотя по стилю немного похоже. Поэтому обращаюсь к автору статьи и плагина. Есть люди которые знают зачем им это нужно. В данном случае автор получал не материальное вознаграждение в виде удовлетворения самолюбия. Возможно кроме этого было косвенное материальное вознаграждение в виде преимущества в резюме хотя я не утверждаю что это было. И наконец багрепорт который автор получил от тысяч юсеров.
Теперь самое интересное. Если разработчики поставили в зависимость чей то код то вправе ожидать что этот код будет поддерживаться и не придётся переделывать проект. Так что если нет серьёзной мотивации то публиковать свою разработку не надо. Лучше сразу поставить цену и посмотреть сколько сотен тысяч скачиваний будет после этого.
И да и нет. В grqphql пользователь определяет описание объекта похожее на спецификацию OpenAPI/swagger. Здесь же определяются какие функции (resolvers) отвечают за формирование ответов. За время потраченное на комментирование честно можно было бы хотя бы для того чтобы вывести меня на чистую воду просмотреть вводный курс graphql это займет не более 10 минут. Ну не пересказывать же мне его или чего доброго не копипастить же его в комменты.
Например если вы сейчас разрабатываете на PHP то вот на Хабре есть статья с простым примером. habrahabr.ru/post/328122
Проблема не совсем в этом. В том что можно подменить iframe который надежный от процессинга на свой который отправляет данные куда угодно. При этом данные тоде не прозодят через нашии сервера но прозодят через сервера злоумышленника.
Как я уже заметил выше есть у отдельной страницы отдно преимущества с точки зрения клиента — можно посмотреть визуально клиенту на url чтобы отличить фейк. Хотя не так уже многие это делают скорее всего.
Так же iframe можно перегрузить своим фейком из зловредного скрипта. Отдельную страницу если загружать ее не по ссылке, а делать переход по событию на адрес который формируется в локальной переменной JavaScript, изменить практически невозможно.
Вцелом картина такая вырисовывается. Что если доступ к веб-серверу есть у неконтролируемого числа людей, то можно изменить в обоих случаях.
А с точки зрения владельца бизнеса iframe выглядит более привлекательно. Тут важно чтобы было адекватное представление об угрозе. Чисто для инетерса можно поклацать по формам сайтов кде есть карточки и убедиться что на странице есть и открытые поля (то есть не в iframe) и скриты GTM и fb. Я просто не хочу приводить тут ссылки т.к. потом типа обвинят во взломе оно мне надо?
Я скажу так что бывал на таких сайтах где поздравление с покупкой просходило даже после того как я ввоил данные по карточке без остатка а все потому что карточка прошла валидацию и процессинг сформировал ссылку возврата на сайт — которая вообще ничего не гоыорит о статусе таранзакции.
Хотелось бы посмотреть на оригинал или периевод цитаты. Я ее не нашел в переводе популярной книги Джо Селко (который катати был противникам суррогатных ключей судя по его пекомендациям в этой книге).
Есть два момента. Действительно с 1963 года начали использовать индексный метод доступа к данным ISAM который предвосхитил современный базы данных. ФИшкой этого метода было как раз то что в индексе содержались физические адреса данных а доступ к индексу можно было органпзовать по человекопонятным цифрам (например код товара, ISBN и т.п.) Это я о первом абзаце (слова автора)
Что касается цитаты Джо Селко (я конечно надеюсь узнать о первоисточнике цитаты) Хранение индексных наборов было сдорогостоящей операцией а до изобретения НЖМД еще и медленной т.к. для поиска лента перематывалаь в разные стороны. Поэтому реляционную модель реализовывали при помощи плоских файлов и их сортировки по ключу. Это позволяло делать расчеты. Приведу пример. Есть два плоских файла остатки товара и прайс. Оба файла сортируются по коду товара и сливаются в один файл. ПАосле этого полученный файл сортируется например по материально ответсвенному лицу и получаются итоги в денежном выражение «в разрезе» как это было принято говорить материально ответсвенных лиц.
Аттракцион невиланной щедрости (в смысле что он готов заплатить)
+ как я уже сказал фича с запросами которые гибко управляются клиентом. Что является отдельным и существенным преимуществом.
Я всего лишь говорю что 2-х факторная это хорошо там где это нужно. Но не стоит отдавать больше контроля над своими личными данными (координата, голос, номер телефона) там где это не нужно.
Теперь самое интересное. Если разработчики поставили в зависимость чей то код то вправе ожидать что этот код будет поддерживаться и не придётся переделывать проект. Так что если нет серьёзной мотивации то публиковать свою разработку не надо. Лучше сразу поставить цену и посмотреть сколько сотен тысяч скачиваний будет после этого.
Например если вы сейчас разрабатываете на PHP то вот на Хабре есть статья с простым примером. habrahabr.ru/post/328122
Так же iframe можно перегрузить своим фейком из зловредного скрипта. Отдельную страницу если загружать ее не по ссылке, а делать переход по событию на адрес который формируется в локальной переменной JavaScript, изменить практически невозможно.
Вцелом картина такая вырисовывается. Что если доступ к веб-серверу есть у неконтролируемого числа людей, то можно изменить в обоих случаях.
А с точки зрения владельца бизнеса iframe выглядит более привлекательно. Тут важно чтобы было адекватное представление об угрозе. Чисто для инетерса можно поклацать по формам сайтов кде есть карточки и убедиться что на странице есть и открытые поля (то есть не в iframe) и скриты GTM и fb. Я просто не хочу приводить тут ссылки т.к. потом типа обвинят во взломе оно мне надо?
Я скажу так что бывал на таких сайтах где поздравление с покупкой просходило даже после того как я ввоил данные по карточке без остатка а все потому что карточка прошла валидацию и процессинг сформировал ссылку возврата на сайт — которая вообще ничего не гоыорит о статусе таранзакции.