Ой, да элементарно... вот поисковый запрос: intel ftlx1471d3bcv-it. Это оптический SFP+ модуль. Впрочем, тут ещё более-менее, запрошенный товар в результатах есть, и он даже второй (хотя должен быть первым, по идее). Но что в выдаче делают сетевые карты, кулеры, материнские платы, антенны, и даже процессор для ноутбуков? Или токен Intel имеет куда как больший вес, и мы сыпем всё, что относится к брэнду? А бывало, что запросишь что-то с точным указанием модели - и на первой странице, в первой дюжине, нужного вообще нет.
И очень огорчает невозможность указать точную подстроку, которую нужно искать - так, как это делается практически на любом поисковике, обрамив требуемое двойной кавычкой. Всё равно подавляющее большинство найденных товаров в принципе не содержит запрашиваемой подстроки.
До маразма доходит - ищешь через Гугл, указывая поиск только в домене market.yandex.ru. Так и быстрее, и точнее.
Прочитал. Но так и не смог понять - как в топ выдачи поиска умудряются попадать товары, у которых ни в названии, ни в описании нет вообще ни одного "слова" из поискового запроса... Сколько раз уже убеждался, что найти по точному наименованию модели, к примеру, коммутатор - если не безнадёжное, то во всяком случае не самое простое дело. И поиск тебе будет подсовывать что угодно, но только не то, что ты попросил. А ещё - при любом переходе то, что ты искал, тут же и немедленно забывается. А потому лучше любые ссылки открывай в новой вкладке...
Как покупатель, могу сказать - если и есть тот ползунок регулировки баланса, анонсированного в заголовке, то он установлен на 99% в сторону продавца.
Они нужны для обеспечения безопасности ваших данных (скрыть приватные данные, ключи).
Не вводите людей в заблуждение. Никакой безопасности неотображаемые поля не обеспечивают. Да, формально "никто не ищет того, о чём не знает". Но коли речь о безопасности - значит, знает. А исследование структуры хранения - это один из первых этапов исследования системы хранения. И существование неотображаемого поля немедленно будет обнаружено. А затем и получены его данные.
Основное назначение таких полей - сокрытие вводимых при обновлении версии структуры хранения полей, чтобы старый код продолжал работать без проблем, а также сокрытие вычисляемых полей для исключения ошибок при попытке изменения их значения.
Впрочем, битие линейкой по рукам за SELECT * даёт практически тот же эффект.
Этот существенный отрывок говорит следующее: если в версии 5.7 или ранее создать InnoDB таблицу, указав некое значение опции AUTO_INCREMENT, а затем перестартовать сервер, то, поскольку показанный запрос вернёт NULL, то следующая запись получит в качестве значения автоинкремента единицу, а значение указанной выше опции будет проигнорировано. И аналогично - для случаев удаления записей с топом перед рестартом.
Однако я что-то не припоминаю подобных фортелей на практике. И, наоборот, прекрасно помню, что SHOW CREATE TABLE показывал значение опции, которое корректировалось с каждым потенциально-генерирующим запросом и прекрасно переживало рестарт сервера.
автоинкремент в InnoDB работает так: при перезагрузке сервера он выясняет, какой следующий идентификатор будет использоваться, выполняя этот запрос
Вы знаете, я не просто удивлён, а даже где-то изумлён... Это MyISAM работает приблизительно по описанному алгоритму - но никак не InnoDB! Не говоря уж о том, что у таблицы в метаданных есть атрибут AUTO_INCREMENT...
К сожалению, в ближайшие две недели мне ничего, кроме online fiddle, не будет доступно, а их не перегрузишь... но я бы проверил, не является ли наблюдаемое вами следствием того, что всё происходит в контейнере докера.
Интересно, это приблизительно какой древности текст? Уже достаточно давно большинство серверов при наличии в выражении группировки первичного ключа таблицы совершенно не настаивают на включении в выражение остальных полей этой же таблицы без их агрегирования.
А следующие утверждения:
предложение SELECT должно содержать все имена столбцов и агрегатов, которые вы хотите отображать в выходных данных;
предложение GROUP BY должно содержать те же имена столбцов, которые есть и в предложении SELECT.
так и вовсе... ну скажем так - изрядно неточны.
Опять же не знаю, это косяк автора или переводчика, но ROLLUP/CUBE/GROUPING SETS - это ни разу не функции, а модификаторы. Вот GROUPING() - это функция. Которую кстати, следовало бы описать...
Ну и странно, что рассмотрена только одна из двух форм CASE.
По-моему, автор вместо обсуждения тезиса "всё есть файл" почему-то начал обсуждать "всё есть файл на томе", да ещё и добавил "на томе физически ограниченного размера". Неудивительно, что дальше всё пошло наперекосяк.
Да я вообще не понимаю смысла этого кодирования, если просто номер позиции однозначно определяет расположение всех костей, и наоборот. А потому вполне достаточно хранить битовую карту. Не, 1,3 Тбайт - тоже не сахар, но это гораздо более вменяемый объём.
Не нужны. Нерешаемость позиции означает, что эту позицию невозможно получить из финальной - ведь любой ход обратим. И это известная нерешаемая задачка - предложение поменять местами любые две соседние плитки (или обычно говорят о плитках 14 и 15 в стандартном конечном расположении), оставив все остальные плитки на своих местах.
Да, но не автором программ-решателей, опубликованных в статье. Так что у вас получается попытка отдать все лавры создателей библиотеки тому, кто её использует.
Всё-таки ляпнул. Я имею в виду, что на чуть ли не всех торговых площадках поиск - это что-то совершенно невменяемое и непредсказуемое. Хорошо, если введённый запрос позволяет сделать нормальный отбор - обычно так бывает, когда ты вводишь что-то, соответствующее названию категории товара. Но введи конкретную модель - и чего только в выборке по такому запросу нет! вплоть до принципиального отсутствия некоторых из введённых поисковых токенов в описании "найденного" товара. Такое впечатление, что поисковая строка бьётся на токены, и выполняется поиск по OR - по вхождению хотя бы одного из них, и пофиг на остальные. Хорошо, если результат такого "поиска" хотя бы сортируется по релевантности запросу (именно запросу - потому как у торговых площадок своё, какое-то совершенно непонятное, понимание релевантности), ну или хотя бы по количеству найденных токенов (про порядок даже не заикаюсь) - но это большая редкость. Поиск точной подстроки? не, не слышали...
В общем, если искать что-то определённое на торговом портале - то обычно лучше это делать через внешний поисковик типа гугляндекса. Больше шансов.
Вообще-то диффуры тут решает подключенная библиотека. А питон так, передаёт условие, получает результат, и больше вообще ничего не делает.
Ни о чём статья. Просто подробный разбор синтаксиса входных данных для библиотеки и интерпретация её результатов, плюс рекомендации по преобразованию исходного уравнения к наиболее приемлемому для формализации виду - было бы гораздо лучше.
никакого объекта для сравнения размеров не предоставлено
Ну почему? пробитая паркетная доска, благо размеры древесного рисунка вполне себе более-менее одинаковы что у них, что у нас, вполне позволяет прикинуть размеры объекта. И ваша оценка размеров вполне адекватна.
Да щазз... Сам лично пробовал - ставлю чисто дрова. Ну так после первой же перезагрузки вылетает баннер "Получить приложение HP Smart". И затрахаешься его отключать.
Ой, да элементарно... вот поисковый запрос: intel ftlx1471d3bcv-it. Это оптический SFP+ модуль. Впрочем, тут ещё более-менее, запрошенный товар в результатах есть, и он даже второй (хотя должен быть первым, по идее). Но что в выдаче делают сетевые карты, кулеры, материнские платы, антенны, и даже процессор для ноутбуков? Или токен Intel имеет куда как больший вес, и мы сыпем всё, что относится к брэнду? А бывало, что запросишь что-то с точным указанием модели - и на первой странице, в первой дюжине, нужного вообще нет.
И очень огорчает невозможность указать точную подстроку, которую нужно искать - так, как это делается практически на любом поисковике, обрамив требуемое двойной кавычкой. Всё равно подавляющее большинство найденных товаров в принципе не содержит запрашиваемой подстроки.
До маразма доходит - ищешь через Гугл, указывая поиск только в домене market.yandex.ru. Так и быстрее, и точнее.
Прочитал. Но так и не смог понять - как в топ выдачи поиска умудряются попадать товары, у которых ни в названии, ни в описании нет вообще ни одного "слова" из поискового запроса... Сколько раз уже убеждался, что найти по точному наименованию модели, к примеру, коммутатор - если не безнадёжное, то во всяком случае не самое простое дело. И поиск тебе будет подсовывать что угодно, но только не то, что ты попросил. А ещё - при любом переходе то, что ты искал, тут же и немедленно забывается. А потому лучше любые ссылки открывай в новой вкладке...
Как покупатель, могу сказать - если и есть тот ползунок регулировки баланса, анонсированного в заголовке, то он установлен на 99% в сторону продавца.
Не вводите людей в заблуждение. Никакой безопасности неотображаемые поля не обеспечивают. Да, формально "никто не ищет того, о чём не знает". Но коли речь о безопасности - значит, знает. А исследование структуры хранения - это один из первых этапов исследования системы хранения. И существование неотображаемого поля немедленно будет обнаружено. А затем и получены его данные.
Основное назначение таких полей - сокрытие вводимых при обновлении версии структуры хранения полей, чтобы старый код продолжал работать без проблем, а также сокрытие вычисляемых полей для исключения ошибок при попытке изменения их значения.
Впрочем, битие линейкой по рукам за SELECT * даёт практически тот же эффект.
Этот существенный отрывок говорит следующее: если в версии 5.7 или ранее создать InnoDB таблицу, указав некое значение опции AUTO_INCREMENT, а затем перестартовать сервер, то, поскольку показанный запрос вернёт NULL, то следующая запись получит в качестве значения автоинкремента единицу, а значение указанной выше опции будет проигнорировано. И аналогично - для случаев удаления записей с топом перед рестартом.
Однако я что-то не припоминаю подобных фортелей на практике. И, наоборот, прекрасно помню, что SHOW CREATE TABLE показывал значение опции, которое корректировалось с каждым потенциально-генерирующим запросом и прекрасно переживало рестарт сервера.
Вы знаете, я не просто удивлён, а даже где-то изумлён... Это MyISAM работает приблизительно по описанному алгоритму - но никак не InnoDB! Не говоря уж о том, что у таблицы в метаданных есть атрибут AUTO_INCREMENT...
К сожалению, в ближайшие две недели мне ничего, кроме online fiddle, не будет доступно, а их не перегрузишь... но я бы проверил, не является ли наблюдаемое вами следствием того, что всё происходит в контейнере докера.
Интересно, это приблизительно какой древности текст? Уже достаточно давно большинство серверов при наличии в выражении группировки первичного ключа таблицы совершенно не настаивают на включении в выражение остальных полей этой же таблицы без их агрегирования.
А следующие утверждения:
так и вовсе... ну скажем так - изрядно неточны.
Опять же не знаю, это косяк автора или переводчика, но ROLLUP/CUBE/GROUPING SETS - это ни разу не функции, а модификаторы. Вот GROUPING() - это функция. Которую кстати, следовало бы описать...
Ну и странно, что рассмотрена только одна из двух форм CASE.
По-моему, автор вместо обсуждения тезиса "всё есть файл" почему-то начал обсуждать "всё есть файл на томе", да ещё и добавил "на томе физически ограниченного размера". Неудивительно, что дальше всё пошло наперекосяк.
Так это обычная подстановка. Расчётное M на фишке соответствует реальному N.
[offtop] Ну... 50% можно, конечно, называть большим шансом... но уж слишком он детерминированный, чтобы применять качественные оценки. [/offtop]
Да я вообще не понимаю смысла этого кодирования, если просто номер позиции однозначно определяет расположение всех костей, и наоборот. А потому вполне достаточно хранить битовую карту. Не, 1,3 Тбайт - тоже не сахар, но это гораздо более вменяемый объём.
Обмен должен быть "по горизонтали" - то есть меняем не любые две, а две соседние в одной горизонтали (причём ни одна из них - не ноль).
Не нужны. Нерешаемость позиции означает, что эту позицию невозможно получить из финальной - ведь любой ход обратим. И это известная нерешаемая задачка - предложение поменять местами любые две соседние плитки (или обычно говорят о плитках 14 и 15 в стандартном конечном расположении), оставив все остальные плитки на своих местах.
Да, но не автором программ-решателей, опубликованных в статье. Так что у вас получается попытка отдать все лавры создателей библиотеки тому, кто её использует.
Совпадение языков - это всего лишь случайность.
С1 в решении есть С/2 из ответа. Причём результат, полученный программой, вообще-то более корректен, чем эталонный.
Всё-таки ляпнул. Я имею в виду, что на чуть ли не всех торговых площадках поиск - это что-то совершенно невменяемое и непредсказуемое. Хорошо, если введённый запрос позволяет сделать нормальный отбор - обычно так бывает, когда ты вводишь что-то, соответствующее названию категории товара. Но введи конкретную модель - и чего только в выборке по такому запросу нет! вплоть до принципиального отсутствия некоторых из введённых поисковых токенов в описании "найденного" товара. Такое впечатление, что поисковая строка бьётся на токены, и выполняется поиск по OR - по вхождению хотя бы одного из них, и пофиг на остальные. Хорошо, если результат такого "поиска" хотя бы сортируется по релевантности запросу (именно запросу - потому как у торговых площадок своё, какое-то совершенно непонятное, понимание релевантности), ну или хотя бы по количеству найденных токенов (про порядок даже не заикаюсь) - но это большая редкость. Поиск точной подстроки? не, не слышали...
В общем, если искать что-то определённое на торговом портале - то обычно лучше это делать через внешний поисковик типа гугляндекса. Больше шансов.
Вообще-то диффуры тут решает подключенная библиотека. А питон так, передаёт условие, получает результат, и больше вообще ничего не делает.
Ни о чём статья. Просто подробный разбор синтаксиса входных данных для библиотеки и интерпретация её результатов, плюс рекомендации по преобразованию исходного уравнения к наиболее приемлемому для формализации виду - было бы гораздо лучше.
(главное, не ляпнуть чего про поиск) Упс...
Ну почему? пробитая паркетная доска, благо размеры древесного рисунка вполне себе более-менее одинаковы что у них, что у нас, вполне позволяет прикинуть размеры объекта. И ваша оценка размеров вполне адекватна.
Если у него ставится WIA-драйвер, то можно попробовать в обход смарта, софтом третьих фирм.
Да щазз... Сам лично пробовал - ставлю чисто дрова. Ну так после первой же перезагрузки вылетает баннер "Получить приложение HP Smart". И затрахаешься его отключать.