Поэтому для SQL Server, особенно если делается поддержка разных языков, нужно использовать другой тип данных: declare @passport_full NCHAR(10) set @passport_full = N’IVЯЛ636805’ collate Arabic_CI_AS select @passport_full
А оно почти никогда не синусоида. Оно что-то приближенное к синусоиде, многие электроприборы вводят паразитные гармоники в сигнал, искажая изначальную форму.
Кстати, да, хороший пример нарушения сразу первой и второй нормальных форм уже на картинке к посту. Если в остальном учебнике такое же пренебрежение основами проектирования БД, то я своё мнение об учебнике уже составил.
Я как разработчик БД на MS SQL ещё больше не люблю использование managed кода процедур, т.к. утечка памяти в таком коде нормально не дебажится и в непредсказуемый момент кладёт сервер с высокой вероятностью на всех версиях, на которых я работал с managed кодом.
Попытка запихнуть в базу то, чего там быть не должно, часто заканчивается плачевно.
select value from (select row_number() over () as value from sys.objects cross join sys.objects) as t where value < @your_number
В таком виде, наверное, не сработает,пишу по памяти с телефона, но общий смысл должен быть ясен. Если чисел не хватит, можно ещё кросс джойнов добавить, за эталон взяв пустую базу, как базу с минимальным количеством объектов.
У вас очень много по статье таких "наивных" неправильных примеров. Проблема как раз в этом - материал вроде бы расчитан на новичков, которые могут взять и скопировать такой пример, не подумав достаточно, и огрести себе проблем с этим в дальнейшем. Из-за чего окажется, что полезность вашей статьи по общему объему причиненных последствий скорее отрицательная. Мое мнение, что лучше никаких примеров не давать, чем давать такие.
Достаточно представить таблицу, в которой 1000 записей со статусом active, 1000 записей со статусом new, мысленно применить к ней два скрипта и подумать, что будет в итоге.
Коллекция прогоняется целиком по порядку - все запросы идут один за другим, и либо проходят проверку, либо нет? Можно ли сделать условное выполнение - вызвали первый метод с запросом на формирование некоей сущности, далее вызываем второй метод статуса сущности, и если статус верный, вызываем третий запрос, с проверкой ответа, а если статус неверный (сущность ещё не обработана) - ждем N секунд и повторно вызываем метод статуса, и так до тех пор, пока не дождемся нужного статуса или не пройдет M попыток?
Странное разделение по четверти статьи. Для маленькой статьи разделение будет слишком подробным - если статья на одну страницу влезает - разделение на 1/4, 1/2 и 3/4 вряд ли будет показательным. Для больших статей - наоборот, недостаточная детализация. Было бы круто считать статистику по главам в тексте. Если текст корректно оформлен и в нем есть заголовки - вот для каждой главы со своим подзаголовком и считать бы статистику.
Это ещё и дополнительный мотив правильно оформлять свой текст, не забывая про разбиение на логические главы - чтобы посмотреть, какую главу прочитали, а какую - пролистали.
Чувствуется, что нанимающие не переросли СССР.
Это тогда же, если ты приходил на завод после ПТУ, например, ты мог на своей должности токаря 1-2-го разряда зарабатывать какие то жалкие 180 рублей в месяц.
А вот если ты приходил после высшего образования — все, ты потратил 5 лет на учебу, ты уже был ИТР, и мог расчитывать на свои гордые 120 рублей )
Это немного спорное утверждение, т.к. да, понятие вроде как постарались вычистить, и соответствующая глава теперь называется «Прекращение трудового договора», но если поискать по тексту кодекса слово «Увольнение» в разных падежах — оно встречается 102 раза.
Да, вроде получше, хотя можно было и совсем упоминания хинтов выкинуть, но это уже не критично — можно и оставить для увеличения глоссария читающего.
Ну и небольшое пожелание по индексам (раз уж перечитал их):
Совсем другое дело, если книги отсортированы по авторам. А внутри автора — по названию.
Если повесить его на колонку таблицы, поиск по ней пойдет быстрее!
Вот тут у вас пример про многоколоночный индекс, а вывод — про одноколоночный. Можно расширить вывод, что индекс можно повесить на несколько нужных колонок (только есть ограничения в размерах, но это уже тонкости), главное — не забывать порядок поиска в индексе. Если у нас индекс сначала по автору а потом по названию, то если нам нужно найти книгу по названию — такой индекс нам будет бесполезен и придется все равно пересматривать все книги, поэтому, если нам часто нужно искать по названию и почти никогда — только по автору, имеет смысл поменять порядок в индексе — сначала название, потом автор.
Про статистику и планы в целом ок, индексы создавать в целом не задача тестировщика, но понимание будет полезным и если он сможет увидеть на плане отсутствие нужного индекса — это тоже полезные умения, так что да, в таком виде будет лучше, наверное.
За рассказ про хинты в статье для «начинающих» отдельный огромный дизреспект. Вот начитаются таких статей, и потом начинают гуглить самые популярные хинты и куда их вставлять.
Тем более что далее идет рассказ по большей части не про хинты а про план выполнения — и это действительно может быть полезно для тестировщиков в плане «как посмотреть план, сохранить его и отправить разработчикам», но, в основном, для тестировщиков, работающих с одной конкретной СУБД с помощью одного конкретного приложения.
В общем и целом, статья требует огромной редакторской работы от нормального разработчика БД, очень много что требует правок, в текущем виде я даже не знаю, чего больше — пользы или вреда. Наверное, все таки пользы для совсем уж новичков, но жалко, что не сделан тот небольшой, но важный вклад от профессионала, который позволил бы избежать таких явных ошибок.
В психологии это называют "модель психического" (сокращение от "модель психического состояния человека").
Термин может быть и неудобный, зато это устоявшийся перевод англоязычного термина "theory of mind".
Упомяну ещё одну вещь.
Не знаю, какую именно базу данных вы подразумеваете, но в SQL Server, например, CHAR - это non-Unicode поле, а Unicode поле - NCHAR.
И в этом случае вас могут ждать другие сюрпризы (взял для примера номер советского паспорта и первую попавшуюся кодировку):
declare @passport_full CHAR(10)set @passport_full = ‘IVЯЛ636805’ collate Arabic_CI_ASselect @passport_fullИ получаем вот такой вот "отличный" результат:
Поэтому для SQL Server, особенно если делается поддержка разных языков, нужно использовать другой тип данных:
declare @passport_full NCHAR(10)set @passport_full = N’IVЯЛ636805’ collate Arabic_CI_ASselect @passport_fullА оно почти никогда не синусоида. Оно что-то приближенное к синусоиде, многие электроприборы вводят паразитные гармоники в сигнал, искажая изначальную форму.
Кстати, да, хороший пример нарушения сразу первой и второй нормальных форм уже на картинке к посту. Если в остальном учебнике такое же пренебрежение основами проектирования БД, то я своё мнение об учебнике уже составил.
Я как разработчик БД на MS SQL ещё больше не люблю использование managed кода процедур, т.к. утечка памяти в таком коде нормально не дебажится и в непредсказуемый момент кладёт сервер с высокой вероятностью на всех версиях, на которых я работал с managed кодом.
Попытка запихнуть в базу то, чего там быть не должно, часто заканчивается плачевно.
Держите магию.
select value from (select row_number() over () as value from sys.objects cross join sys.objects) as t where value < @your_number
В таком виде, наверное, не сработает,пишу по памяти с телефона, но общий смысл должен быть ясен. Если чисел не хватит, можно ещё кросс джойнов добавить, за эталон взяв пустую базу, как базу с минимальным количеством объектов.
У вас очень много по статье таких "наивных" неправильных примеров. Проблема как раз в этом - материал вроде бы расчитан на новичков, которые могут взять и скопировать такой пример, не подумав достаточно, и огрести себе проблем с этим в дальнейшем. Из-за чего окажется, что полезность вашей статьи по общему объему причиненных последствий скорее отрицательная.
Мое мнение, что лучше никаких примеров не давать, чем давать такие.
Так вроде довольно очевидно и без подсказки )
Достаточно представить таблицу, в которой 1000 записей со статусом active, 1000 записей со статусом new, мысленно применить к ней два скрипта и подумать, что будет в итоге.
-- upUPDATEusersSETstatus = 'active'WHEREstatus = 'new';-- downUPDATEusersSETstatus = 'new'WHEREstatus = 'active';Мимо. Второй скрипт не откатит состояние таблицы к тому, которое было до наката первого скрипта. Подсказать, почему, или и так понятно? )
Спасибо, надо будет в следующий раз попробовать полноценно процесс автоматизировать таким способом.
Коллекция прогоняется целиком по порядку - все запросы идут один за другим, и либо проходят проверку, либо нет?
Можно ли сделать условное выполнение - вызвали первый метод с запросом на формирование некоей сущности, далее вызываем второй метод статуса сущности, и если статус верный, вызываем третий запрос, с проверкой ответа, а если статус неверный (сущность ещё не обработана) - ждем N секунд и повторно вызываем метод статуса, и так до тех пор, пока не дождемся нужного статуса или не пройдет M попыток?
Странное разделение по четверти статьи. Для маленькой статьи разделение будет слишком подробным - если статья на одну страницу влезает - разделение на 1/4, 1/2 и 3/4 вряд ли будет показательным. Для больших статей - наоборот, недостаточная детализация. Было бы круто считать статистику по главам в тексте. Если текст корректно оформлен и в нем есть заголовки - вот для каждой главы со своим подзаголовком и считать бы статистику.
Это ещё и дополнительный мотив правильно оформлять свой текст, не забывая про разбиение на логические главы - чтобы посмотреть, какую главу прочитали, а какую - пролистали.
Нарушает одно из правил — «Шаг ставок — 1 доллар»
Это тогда же, если ты приходил на завод после ПТУ, например, ты мог на своей должности токаря 1-2-го разряда зарабатывать какие то жалкие 180 рублей в месяц.
А вот если ты приходил после высшего образования — все, ты потратил 5 лет на учебу, ты уже был ИТР, и мог расчитывать на свои гордые 120 рублей )
19) Почему у ежей выпадают зубы и как правильно их лечить
Это немного спорное утверждение, т.к. да, понятие вроде как постарались вычистить, и соответствующая глава теперь называется «Прекращение трудового договора», но если поискать по тексту кодекса слово «Увольнение» в разных падежах — оно встречается 102 раза.
Ну и небольшое пожелание по индексам (раз уж перечитал их):
Вот тут у вас пример про многоколоночный индекс, а вывод — про одноколоночный. Можно расширить вывод, что индекс можно повесить на несколько нужных колонок (только есть ограничения в размерах, но это уже тонкости), главное — не забывать порядок поиска в индексе. Если у нас индекс сначала по автору а потом по названию, то если нам нужно найти книгу по названию — такой индекс нам будет бесполезен и придется все равно пересматривать все книги, поэтому, если нам часто нужно искать по названию и почти никогда — только по автору, имеет смысл поменять порядок в индексе — сначала название, потом автор.
Тем более что далее идет рассказ по большей части не про хинты а про план выполнения — и это действительно может быть полезно для тестировщиков в плане «как посмотреть план, сохранить его и отправить разработчикам», но, в основном, для тестировщиков, работающих с одной конкретной СУБД с помощью одного конкретного приложения.
В общем и целом, статья требует огромной редакторской работы от нормального разработчика БД, очень много что требует правок, в текущем виде я даже не знаю, чего больше — пользы или вреда. Наверное, все таки пользы для совсем уж новичков, но жалко, что не сделан тот небольшой, но важный вклад от профессионала, который позволил бы избежать таких явных ошибок.