регистр не учитывается что это значит
Я видел одну или две темы, в которых говорилось о чувствительности к регистру, но мой вопрос более конкретный.
Я понимаю, например, интерес к поиску без учета регистра по текстовым значениям.
Но зачем нам использовать имена, таблицы и столбцы баз данных без учета регистра?
3 ответа
SQL: 2008 и Стандарты SQL-99 определяют, что базы данных нечувствительны к регистру идентификаторов, если они не указаны в кавычках. Я обнаружил, что большинство ORM цитируют идентификаторы в генерируемом ими SQL.
Однако, как вы, вероятно, знаете, не все реляционные базы данных строго соответствуют стандартам. DB2 и Oracle на 100% совместимы. PostgreSQL в основном совместим, за исключением того факта, что он автоматически переводит в нижний регистр все, что не указано в кавычках (что лично я предпочитаю).
MySQL становится немного странным, поскольку он хранит каждую таблицу как файл в файловой системе. По этой причине это зависит от чувствительности к регистру файловой системы. В Windows:
SQL Server еще более странный. Он сохранит регистр при создании, однако позволит вам ссылаться на него любым способом после (даже если вы укажете имя!). Вы не можете создать две таблицы, единственное отличие которых заключается в их корпусе. Примечание. В SQL Server есть параметры конфигурации, которые управляют этим, например чувствительность к регистру идентификаторов будет зависеть от параметров сортировки по умолчанию для экземпляра базы данных. Как сбивает с толку!
Хотя по большей части я согласен с вами, что компьютеры (языки программирования, базы данных, файловые системы, URL-адреса, пароли и т. Д.) Должны учитывать регистр, все системы реализованы независимо и могут или не могут придерживаться стандартам, которые могут существовать, а могут и не существовать. Внедрение базы данных с учетом регистра определенно возможно, если вы знаете все тонкости своей конкретной системы баз данных и ее поведение.
Основное преимущество использования чувствительности к регистру заключается в том, что когда мы развертываем его на клиентском сайте, наша БД работает независимо от того, настроен ли клиентский SQL Server с учетом регистра или нет, так что да, это действительно не очень хорошая идея, и я не знать, почему кто-то может использовать таблицы / столбцы базы данных без учета регистра.
Если бы вы переделали всю ИТ-индустрию сегодня, обладая знаниями и технологиями, вы могли бы по умолчанию делать все с учетом регистра, за исключением тех вещей, о которых особенно просили не учитывать регистр.
Но еще до того, как я родился, и даже когда я начал работать (ладно, играть) с компьютерами, многие компьютеры не могли даже различать прописные и строчные буквы. Я создаю довольно сложную карту, которую вставляю в свое поддельное яблоко II, чтобы она понимала разницу.
Так что я думаю, что в те дни разница между верхним и нижним регистром была чем-то вроде дисплея сетчатки. Круто, если оно у вас есть. И через 10 лет мы можем спросить, почему кто-то когда-либо создавал приложение без таких дисплеев, но сегодня это просто не так актуально.
То же самое верно и для баз данных (и файловых систем), поскольку многие из них и соответствующие им стандарты восходят, по крайней мере, к 70-м годам.
1С и чувствительность к регистру [поход на грабли]
Предыстория
Поиск по данным в базе
Заметим, что таким образом мы можем задать элементу справочника код А00001 и при автонумерации получим А00002, А00003 и так далее. Так же мы можем задать код а00001 и получить а00002, а00003. Но если мы при наличии А00001 по какой-то причине захотим установить номер а00001, то получить «облом».
Итак, поисковые методы менеджеров объектов отказываются правильно искать чувствительные к регистру символов данные. А можно ли самостоятельно создать подобные методы с помощью механизма запросов? Давайте попробуем:
Т.е. для текста запроса, который транслируется в SQL и выполняется во внешних СУБД, снова верно выражение: 1040 = КодСимвола(«А») = КодСимвола(«а») = 1072. Я уже приготовился, что все во что я верил ложно и в мире 1С будет справделиво («А» = «а») = Истина, но к счастью хотя бы примитивное сравнение строк работает и нужную нам функцию все же можно создать:
Поиск по коллекциям
Заключение
Выход, как мы видим, существует. Тут можно написать поисковую функцию с перепроверкой результата. Еще можно вместо поиска перед основным алгоритмом создать соответствие, где по строковым ключам загнать значение соответствующих ссылок. Но хотелось бы применять подобные костыли реже.
Настройка учета регистра
Чувствительность к регистру определяет, обрабатываются ли прописные (FOO.txt) и строчные буквы (foo.txt) как уникальные (с учетом регистра) или эквивалентные (без учета регистра) в имени файла или каталога.
различия между Windows и учетом регистра Linux
при работе с файлами и каталогами Linux и Windows может потребоваться изменить способ обработки чувствительности к регистру.
Windows файловая система поддерживает настройку чувствительности к регистру с помощью флагов атрибутов на каталог. Хотя стандартное поведение не зависит от регистра, можно назначить флаг атрибута, чтобы сделать каталог чувствительным к регистру, чтобы он мог распознать файлы и папки Linux, которые могут отличаться только регистром.
это может быть особенно справедливо при подключении дисков к файловой системе подсистема Windows для Linux (WSL). При работе в файловой системе WSL вы используете Linux, поэтому файлы и каталоги по умолчанию обрабатываются как регистр.
в прошлом, если у вас есть файлы, имена которых отличаются только регистром, Windows не удалось получить доступ к этим файлам, так как Windows приложения рассматривают файловую систему как нечувствительное к регистру и не могут различить файлы, имена которых отличаются только регистром. хотя в Windows Explorer будут показаны оба файла, будет открыт только один из них, независимо от выбранного.
Изменение чувствительности к регистру файлов и каталогов
ниже описано, как изменить каталог в файловой системе Windows так, чтобы он заменялся с учетом регистра, а также распознать файлы и папки, отличающиеся только регистром.
некоторые Windows приложения с учетом предположения, что файловая система не учитывает регистр, не используйте правильный регистр для ссылки на файлы. Например, приложения не слишком часто преобразовывают имена файлов для использования всех прописных и строчных букв. В каталогах, помеченных с учетом регистра, это означает, что эти приложения больше не имеют доступа к файлам. кроме того, если Windows приложения создают новые каталоги в дереве каталогов, где используются файлы с учетом регистра, то в этих каталогах не учитывается регистр. это может усложнить работу с Windows инструментами в каталогах с учетом регистра, поэтому следует соблюдать осторожность при Windows изменении параметров чувствительности к регистру в файловой системе.
Проверить чувствительность к текущему регистру
чтобы проверить, учитывается ли регистр в каталоге в Windows файловой системе, выполните команду:
путь к файлу. для каталога в файловой системе Windows (NTFS)
будет выглядеть так: C:\Users\user1\case-test или, если вы уже находится в user1 каталоге, можно просто запустить: fsutil.exe file setCaseSensitiveInfo case-test
Изменить чувствительность к регистру
Чтобы изменить чувствительность каталога к регистру, необходимо запустить повышенные разрешения (Запуск от имени администратора). Изменение флага учета регистра также требует наличия разрешений «запись атрибутов», «Создание файлов», «Создание папок» и «Удаление вложенных папок и файлов» в каталоге. Дополнительные сведения об этом см. в разделе Устранение неполадок.
чтобы изменить каталог в Windows файловой системе так, чтобы он был чувствителен к регистру (foo ≠ FOO), запустите PowerShell от имени администратора и используйте команду:
чтобы изменить каталог в Windows файловой системы на значение по умолчанию без учета регистра (foo = foo), запустите PowerShell от имени администратора и выполните команду:
Каталог должен быть пустым, чтобы изменить атрибут флага чувствительности к регистру в этом каталоге. Нельзя отключить флаг чувствительности к регистру для каталога, содержащего папки и файлы, имена которых отличаются только регистром.
Наследование чувствительности к регистру
При создании новых каталогов эти каталоги будут наследовать учет регистра от родительского каталога.
При работе в режиме WSL 1 возникает исключение из этой политики наследования. Если распределение выполняется в режиме WSL 1, флаг учета регистра для каталога не наследуется; каталоги, созданные в каталоге с учетом регистра, автоматически не чувствительны к регистру. Необходимо явно пометить каждый каталог как чувствительный к регистру
Варианты чувствительности к регистру для подключения диска в файле конфигурации WSL
Чтобы настроить параметр учета регистра в wsl.config файле при подключении диска, выполните следующие действия.
Значение по умолчанию: Включение учета регистра для каждого каталога.
Чувствительность к регистру недоступна (все каталоги на подключенных дисках NTFS будут учитываться без учета регистра):
Обрабатывать все каталоги на диске (NTFS) с учетом регистра:
Изменение чувствительности регистра на диске, подключенном к WSL распределению
Диски в формате NTFS, подключенные к дистрибутиву WSL, по умолчанию не учитывают регистр. Изменение чувствительности регистра для каталога на диске, подключенном к WSL дистрибутиву (IE. Ubuntu), выполните те же действия, которые перечислены выше для Windows файловой системы. (По умолчанию диски EXT4 будут учитываться с учетом регистра).
Чтобы включить чувствительность к регистру в каталоге (FOO ≠ foo), используйте команду:
Чтобы отключить чувствительность к регистру в каталоге и вернуться к регистру без учета регистра по умолчанию (FOO = foo), используйте команду:
При изменении флага с учетом регистра для существующего каталога для подключенного диска во время работы WSL убедитесь, что WSL не содержит ссылок на этот каталог, иначе изменение не вступит в силу. Это означает, что каталог не должен быть открыт какими-либо процессами WSL, включая использование каталога (или его потомков) в качестве текущего рабочего каталога.
Настройка чувствительности к регистру с помощью Git
Система управления версиями Git также имеет параметр конфигурации, который можно использовать для настройки чувствительности к регистру для файлов, с которыми вы работаете. Если вы используете Git, может потребоваться изменить git config core.ignorecase параметр.
Чтобы задать для Git регистр с учетом регистра (FOO.txt ≠ foo.txt), введите:
git config core.ignorecase false
Чтобы задать для Git регистр без учета регистра (FOO.txt = foo.txt), введите:
git config core.ignorecase true
Установка этого параметра в значение false для файловой системы без учета регистра может привести к путанице с ошибками, ложным конфликтам или дублированию файлов.
Диагностика
мой каталог содержит файлы с учетом регистра и требует учета регистра, но Windows средствам FS не будут распознавать эти файлы
чтобы использовать Windows средствах файловой системы для работы с каталогом Linux, который содержит файлы с разными вариантами, необходимо создать новый каталог с учетом регистра, а затем скопировать файлы в этот каталог (с помощью клона git или распаковать). Файлы останутся в смешанном регистре. (Обратите внимание, что если вы уже пробовали переместить файлы в каталог без учета регистра и возникли конфликты, скорее всего, некоторые файлы были перезаписаны и больше не будут доступны.)
Ошибка: Каталог не пуст
Нельзя изменить параметр чувствительности к регистру для каталога, который содержит другие файлы или каталоги. Попробуйте создать новый каталог, изменить параметр, а затем скопировать в него файлы в смешанных регистрах.
Регистры сведений. История одного «велосипеда»
В свое время, когда я достаточно много занимался собеседованиями кандидатов на должность разработчика 1С, я нашел для себя пару-тройку совсем простых вопросов. Послушав ответы на эти вопросы можно было моментально представить себе уровень кандидата.
Один из вопросов звучал безобидно и просто: «Что такое регистр сведений?» Тем удивительнее было наблюдать, как многие буквально спотыкались об него. Впечатление было такое, как будто человек шел, шел и не заметил стеклянную дверь. Тогда-то я впервые задумался о том, что не так с этим изобретением.
На момент разработки принципиальной схемы будущей платформы 1С:Предприятие 8, уже существовала хорошо проработанная и стройная теория реляционных баз данных. Ее основные понятия: записи (кортежи), таблицы (отношения), индексы, ключи были прекрасно «подогнаны» друг к другу. Все логично и ничего лишнего. Одна лишь проблема. Все это было несколько «абстрактно» для простого человека. Поэтому идея «обернуть» понятия таблиц и связей типа один-ко-многим во что-нибудь более близкое простому человеку сработала на «ура». Назвав таблицы с реквизитом типа «Дата» документами, а таблицы без такового справочниками, создатели получили эффект, наверное, больший, чем сами ожидали. В самом деле, каждый легко мог представить себе что такое справочник и что такое документ. Потому что раньше так или иначе имел с ними дело. В одночасье базы данных стали близкими для широкого круга.
В реальном мире есть как отношения подчинения, так и отношения равноправия. Поэтому в одной записи могут оказаться несколько сущностей с равными правами. Например, если мы хотим отражать в базе данных информацию о том, какие товары по каким ценам мы берем у тех или иных поставщиков (контрагентов), тогда у нас появляются записи вида: «товар», «контрагент», «цена». Здесь «цена» несомненно подчиненная сущность. Но подчинена она уже не какой-то одной а сразу двум другим сущностям.
В теории (да и в практике тоже) баз данных это обыгрывается элементарно. Первичный ключ может быть простым, если у нас отношения подчинения (первый случай) или составным, если у нас отношения равноправия (второй случай). Это решение логично, изящно и настолько просто, что попытки найти здесь «свой путь», несомненно должны проходить по разряду «изобретений велосипеда».
Есть такая задача, которая называется «получение последних значений». Например, у вас в базе имеется следующая информация о закупочных ценах:
01.01.2019, ООО Ромашка, Ложка, 150 р.
01.02.2019, ООО Ромашка, Вилка, 120 р.
01.03.2019, ООО Ромашка, Вилка, 125 р.
01.02.2020, ООО Незабудка, Ложка, 165 р.
01.03.2020, ООО Незабудка, Ложка, 167 р.
01.08.2021, ООО Василек, Ложка, 190 р.
01.08.2021, ООО Василек, Вилка, 155 р.
01.08.2021, ООО Одуванчик, Ложка, 191 р.
Тогда последние цены конкретных товаров у конкретных поставщиков будут следующие:
01.01.2019, ООО Ромашка, Ложка, 150 р.
01.03.2019, ООО Ромашка, Вилка, 125 р.
01.03.2020, ООО Незабудка, Ложка, 167 р.
01.08.2021, ООО Василек, Ложка, 190 р.
01.08.2021, ООО Василек, Вилка, 155 р.
01.08.2021, ООО Одуванчик, Ложка, 191 р.
А последние цены просто товаров, без учета поставщиков:
01.08.2021, Ложка, 190 р.
01.08.2021, Вилка, 155 р.
01.08.2021, Ложка, 191 р.
Получается такое в результате достаточно нехитрой операции группировки и получения максимальных дат, а затем соединения с исходной таблицей. Может применяться к любому набору данных, в котором есть поле типа «Дата».
Разработчики восьмерки почему-то решили, что единственным местом, откуда эта операция может вызываться должен быть как раз регистр сведений. Только не обычный в их понимании, а особенный, который они выделили в отдельный подкласс и назвали «периодическим». Кавычки здесь более чем уместны, потому что никаких периодов там нет. Разработчики воспользовались словом, не вполне отдавая себе отчет в том, что оно означает. Но, по сравнению с остальным, это, в сущности, мелочь. «Периодический» регистр сведений отличается от обычного тем, что в состав первичного ключа помимо измерений входит т.н. «период» (который, конечно не период, а просто поле типа «Дата»).
Идея разработчиков заключалась в том, что последние записи должны быть уникальными. И надо сказать, что они верно поняли задачу. Но лучше бы они ее не решали. Если верить Эйнштейну (а у нас нет оснований ему не верить, раз мы пользуемся его формулами практически каждый день), то в реальном мире никакие два события не происходят в точности одновременно. Поэтому, имея поле типа «Дата», которое отмечает точку на временной оси, мы уже имеем уникальность. Достаточно позаботиться о том, чтобы ваша учетная система соответствовала реальному миру в фундаментальных аспектах (а время это именно такой аспект) и создать механизм обеспечивающий уникальность значения типа «Дата» как минимум в рамках информационной базы. Тогда наш результат из вышеприведенного примера естественным образом избавился бы от дублирующих значений:
01.08.2021 00:00:00 78364732678365738465734, Вилка, 155 р.
01.08.2021,00:00:00 78364732678365753438478, Ложка, 191 р.
Но разработчики посчитали, что достаточно будет хранить даты с точностью до секунды. И перед ними встала другая задача. Какой результат выдавать, в случае если запрос к их регистру сведений строится по неполному набору ключевых полей, как это было показано выше. Можно было бы выдавать результат:
01.08.2021, Ложка, 190 р.
01.08.2021, Вилка, 155 р.
01.08.2021, Ложка, 191 р.
Но это внезапно ломало концепцию уникальности последних записей. Можно было бы вызывать исключительную ситуацию при попытке построить запрос к регистру сведений. И, повторюсь, все-таки лучшим решением было обеспечение уникальности значений типа «Дата». Что же сделали разработчики, столкнувшись с очередной трудностью? А ничего! Вот просто ничего. В текущей реализации запрос к регистру сведений по неполному набору «измерений» вернет:
01.01.2019, Ложка, 150 р.
01.03.2019, Вилка, 125 р.
01.03.2020, Ложка, 167 р.
01.08.2021, Ложка, 190 р.
01.08.2021, Вилка, 155 р.
01.08.2021, Ложка, 191 р.
Как видите, результат не только потерял уникальность, он еще и перестал выдавать последние записи. Он лишен вообще какого-либо смысла. Такое ощущение, что малые дети начали что-то делать, потом у них возникли трудности, они расстроились и бросили все, как есть.
На самом деле все это не так смешно, как я здесь описываю. Потому что в реальности происходит следующее. Вы сталкиваетесь с задачей получения последних записей по неполному набору «измерений». Открываете документацию. В описании виртуальной таблицы среза последних читаете:
«Предназначена для получения наиболее поздних записей регистра сведений на указанную дату (включительно). Включает только активные записи. По каждой комбинации измерений будет найдена наиболее поздняя запись, но не более поздняя, чем указанная дата.»
Делаете вывод, что ваш запрос вернет вам последние записи, а в результате получаете бессмыслицу. Проблема здесь не только в том, что вы теряете время. Хотя и это тоже важно, если учесть, что разработчиков в 1С десятки тысяч. Гораздо серьезнее следующее. Если вы полностью доверяете разработчикам платформы, то вы не станете дотошно проверять результат и можете элементарно пропустить эту ошибку. А если вы уже обожглись на чем-то другом и теперь проверяете все досконально, то и тут нет ничего хорошего. Потому что невозможно нормально работать, если знаешь, что от разработчиков платформы можно в любой момент ожидать чего угодно.
Немного о регистрах в 1с
В любой конфигурации 1с 8.2 можно увидеть такой вид объектов, как регистры. Основное их предназначение — оптимизация получения данных для отчетов. Существует четыре вида реистров: регистры сведений, регистры накоплений, регистры бухгалтерии и регистры расчета. И хотя предназначены эти виды для решения разных задач, уже по тому, что они все называются «регистрами» можно догадаться, что они имеют и нечто общее.
Во-первых, как уже упоминалось, как объекты конфигурации они нужны для более быстрого считывания информации из базы данных, например в запросах. Регистры можно сравнить с каталогом книжной библиотеки (раньше их составляли на бумажных карточках). То есть это не только хранение информации (данных), но и ее систематизация (создание определенной структуры), когда в конкретный регистр попадают данные (например, из документов разного вида) и при необходимости ее можно достаточно быстро оттуда извлечь и вывести, например, в отчет или обработать иным образом. В общем случае основное использование регистров в 1с можно изобазить следующей схемой: «Документ — Регистр — Отчет», хотя существуют и исключения.
В-третьих, регистры имеют табличную структуру, но она отличается от структуры объектных таблиц. Так что вы не найдете таких классов, как РегистрСсылка или РегистрОбъект. Состав таблицы регистра зависит от его свойств.
В-четвертых, данные в регистры записываеются в виде наборов записей. Каждый набор состоит из одной или нескольких записей. При этом на запись в наборе нельзя сослаться или обратиться к ней. А также ни набор записей, ни запись в наборе не могут иметь состояния «пометка на удаление».
В-пятых, при обращении в запросах к регистрам для получения данных существует возможность обратиться не только к физическим таблицам регистра, но и к виртуальным таблицам, которые представляют из себя вложенный запрос, получающий данные по определенным параметрам. Параметры виртуальной таблицы задаются в зависимости от конкретных потребностей по получению данных из таблиц регистров.
Терперь поговорим об особенностях каждого вида регистров:
1. Регистры сведений
Пожалуй, самый простой вид регистра. В отличие от регистров другого вида, его ресурс может имень не только числовое значение, но и другой тип данных.
Имеет особое свойство, не используемое в других видах регистров — периодичность.
Может не иметь регистратора, то есть быть независимым, в этом случае записи производятся непосредственно в регистр, минуя регистрирующий документ (то самое исключение из общей схемы использования регистров в 1с). Тогда как остальные виды регистров должны иметь хотя бы один документ-регистратор.
Кроме того, данный вид регистра имеет автоматический контроль уникальности записей по периоду (периодичность, указанная в свойствах регистра) и измерениям. То есть среди записей регистра не может быть более одной записи с одинаковыми показателями период+измерение+регистратор(если он есть). Уникальность записей в других видах регистров осуществляется по регистратору.
2. Регистры накоплений
Предназначен для накопления числовых покателей (ресурсов) и делится на два подвида — Остатки и Обороты. Отличие между ними заключается в том, что Регистр накопления Остатки предназначен для получения информации о состоянии «на момент времени», а Обороты — информации о данных «за период».
Данные регистра накопления хранятся в БД в виде двух таблиц — таблица движений и таблица итогов. Обращение напрямую возможно только к таблице движений.
3. Регистры бухгалтерии
Похож на регистр накопления, но предназназначен для систематизации данных о бухгалтерских проводках. Впрочем он может использоваться не только для бухгалтерского, но и для любого другого вида учета.
4. Регистры расчета
Этот вид регистра предназначен не только для хранения, накопления и систематизации данных, но и для реализации сложных механизмов периодческих расчетов. Для этого в свойствах регистра расчета необходимо определить еще один объект 1с — план видов расчета. То есть работа регистра этого вида невозможна без определения для него конкретного плана видов расчета.
Можно сказать, что регистр расчета используется и для хранения информации о видах расчета, и для хранения результатов расчетов, и для промежуточных значений расчетов. Основное его предназначение в конфигурациях 1с — это расчеты начислений, например, заработной платы и других выплат сотрудникам. И для реализации этих задач при определении параметров регистра расчета, в нем возможно указать связь с графиком времени, что позволяет производить расчеты в зависимости от того времени, которое задано в этом графике. Сам график времени должен быть определен с помощью соответствующего регистра сведений.
Таким образом, можно сказать, что регистр расчета имеет в итоге самую сложную структуру по сравнению с другими видами регистров в 1с.