допустим, я оформил скидочные карты в Пятерке, Магните, и еще в паре аптек. Мне обязательно устанавливать их приложение на смартфон? Для чего? Чтобы что? Чтобы они меня задалбывали уведомлениями, а я лез в телефон и эти уведомления явно отрубал? Я приду сам в магазин, куплю что мне надо в данный момент, а для скидки покажу карточку (или картинку со штрихкодом на телефоне). Само приложение мне для чего? Выискивать скидки в 5-ти разных магазинах вокруг? Так пенсионеры (я еще нет) этого всё равно делать не умеют.
плюсану. Каждая п...а пытается заставить меня установить своё приложение на телефон, которое мне нафиг не нужно. Мне даже (о ужас!) не нужны госуслуги на телефоне. Но тут вступает в дело отсутствие у людей десктопных компьютеров, которых у них никогда не было. С обратной стороны, засилье приложений для владельцев десктопов - явная дискриминация.
так уже как минимум год назад мошенники присылали смс с кодом на банки.ру, специально для взятия кредитов. И тут на хабре была мощная статья про кредитный спам оттуда при элементарной регистрации на сайте.
не, хорошо описано. Я С/C++ не люблю, но со внутренностями ФБ крайне знаком, у вас хорошее исследование. Понятно что вы не докопались до ряда вещей, но всё еще впереди :-)
см. ods.h/ods.hpp, там есть структура записи, в которой есть в начале номер формата. Но, форматы меняются и записываются только при изменении структуры таблицы, а не при записи версий, боже упаси.
Если я правильно понял вопрос: Здесь речь именно про "ванильный Firebird". А "продвинутые Firebird" - это HQbird и RedDatabase, которые в статье не упоминаются. И у которых совсем другие "свои фишки", про которые в статье также не упоминается (и даже не имеются в виду). То, что упоминается в статье, одинаково и у ванильного Firebird, и у продвинутых HQbird и RedDatabase.
А "почему понадобился переход..." - про это в самом начале первой части статьи.
а ему это надо? Должно быть письмо, с уведомлением и описью, и у отправителя и у получателя. Если у получателя его нет, то отправитель имеет подтверждающий документ. А распечатанный емэйл - ну это фигня какая-то. Это разве что ответчик в суде может предъявлять. Но прокурор сам такие письма себе как оправдание печатать не будет.
я видел базу, в которой были только ПК, и ни одного ФК. Целостность связей поддерживалась (якобы) на уровне внешнего приложения. Но такое решение существовало лет 20 назад, и скорее всего уже давно сгинуло.
"В некоторых случаях" - да. если связь по ФК подразумевает малое количество "справочных" значений, которые используются в огромной таблице. В ERP даже бывает, что такое "справочное значение" вообще одно.
ваша шутка оч. могучая, конечно. Впрочем, если автор оригинального текста живет в США, то там - да, Firebird не имеет популярности. А вот в Бразилии, России, и ряде стран Европы - очень даже.
Если полнотекстовый поиск и CTE - вполне нормальные фичи, то вот за хранение атрибутов как указано в примерах первого пункта (JSON), я бы просто порол. Эти атрибуты должны быть в таблице пользователей или связанных таблицах. Т.е. нужно нормально проектировать структуру БД, а не втыкать туда JSON в невообразимом виде, а потом мучиться с тормозными запросами. В общем, крайне плохой пример в отношении JSON, особенно "для начинающих".
я и не устанавливаю. А "с компьютера" эти карты мне тем более не нужны.
допустим, я оформил скидочные карты в Пятерке, Магните, и еще в паре аптек. Мне обязательно устанавливать их приложение на смартфон? Для чего? Чтобы что?
Чтобы они меня задалбывали уведомлениями, а я лез в телефон и эти уведомления явно отрубал? Я приду сам в магазин, куплю что мне надо в данный момент, а для скидки покажу карточку (или картинку со штрихкодом на телефоне).
Само приложение мне для чего? Выискивать скидки в 5-ти разных магазинах вокруг? Так пенсионеры (я еще нет) этого всё равно делать не умеют.
плюсану. Каждая п...а пытается заставить меня установить своё приложение на телефон, которое мне нафиг не нужно. Мне даже (о ужас!) не нужны госуслуги на телефоне.
Но тут вступает в дело отсутствие у людей десктопных компьютеров, которых у них никогда не было. С обратной стороны, засилье приложений для владельцев десктопов - явная дискриминация.
сейчас там регистрироваться никакого смысла нет.
при чем тут перс. данные. Там давно регистрация по номеру телефона, после чего на этот телефон шлют массово предложения по кредитам.
так уже как минимум год назад мошенники присылали смс с кодом на банки.ру, специально для взятия кредитов. И тут на хабре была мощная статья про кредитный спам оттуда при элементарной регистрации на сайте.
пока я куриль
мне кто-то звониль
ничего, харашо
позвонит ишшо
вообще не понимаю зачем перезванивать на непонятные номера. Я могу перезвонить личному контакту, на номер, с которого он только что звонил. И всё.
нет. IBExpert это Хвастунов, который в HK-Software (Германия). Заблочено сразу с началом СВО.
не, хорошо описано. Я С/C++ не люблю, но со внутренностями ФБ крайне знаком, у вас хорошее исследование. Понятно что вы не докопались до ряда вещей, но всё еще впереди :-)
см. ods.h/ods.hpp, там есть структура записи, в которой есть в начале номер формата. Но, форматы меняются и записываются только при изменении структуры таблицы, а не при записи версий, боже упаси.
Если я правильно понял вопрос:
Здесь речь именно про "ванильный Firebird". А "продвинутые Firebird" - это HQbird и RedDatabase, которые в статье не упоминаются. И у которых совсем другие "свои фишки", про которые в статье также не упоминается (и даже не имеются в виду).
То, что упоминается в статье, одинаково и у ванильного Firebird, и у продвинутых HQbird и RedDatabase.
А "почему понадобился переход..." - про это в самом начале первой части статьи.
!
косты, не "касты"
а ему это надо? Должно быть письмо, с уведомлением и описью, и у отправителя и у получателя. Если у получателя его нет, то отправитель имеет подтверждающий документ.
А распечатанный емэйл - ну это фигня какая-то. Это разве что ответчик в суде может предъявлять. Но прокурор сам такие письма себе как оправдание печатать не будет.
"Шаг 1...
Если в результатах видно, что ECH включен..."
Поясните пожалуйста, как это должно быть видно, например.
ну, была когда-то статья Тенцера "Естественные ключи против искусственных ключей".
Я за surrogate primary keys :-)
я видел базу, в которой были только ПК, и ни одного ФК. Целостность связей поддерживалась (якобы) на уровне внешнего приложения.
Но такое решение существовало лет 20 назад, и скорее всего уже давно сгинуло.
"В некоторых случаях" - да. если связь по ФК подразумевает малое количество "справочных" значений, которые используются в огромной таблице. В ERP даже бывает, что такое "справочное значение" вообще одно.
ваша шутка оч. могучая, конечно. Впрочем, если автор оригинального текста живет в США, то там - да, Firebird не имеет популярности. А вот в Бразилии, России, и ряде стран Европы - очень даже.
автор очень аккуратно не упомянул Firebird...
Если полнотекстовый поиск и CTE - вполне нормальные фичи, то вот за хранение атрибутов как указано в примерах первого пункта (JSON), я бы просто порол.
Эти атрибуты должны быть в таблице пользователей или связанных таблицах. Т.е. нужно нормально проектировать структуру БД, а не втыкать туда JSON в невообразимом виде, а потом мучиться с тормозными запросами.
В общем, крайне плохой пример в отношении JSON, особенно "для начинающих".