|
Юникод и utf8
|
|||
---|---|---|---|
#18+
maytonEugene NewКак она может не реагировать, когда вам приходится делать все строковые поля в ДВА раза большего объема. Не писать туда больше, а сразу увеличивать длину полей в байтах в два раза. Раньше надо было 100 байтов, теперь надо 200. Потому что поле может достигать 100 символов длиной на русском языке. Если вы используете русский язык в базе. Для латиницы, повторяюсь, все равно. Для русского языка - катастрофичное увеличение объема. Как я уже писал. Сегментное пространство таблиц состоит из смеси VARCHAR, NUMBER, DATE типов и прочих сырых типов и служебной информации и пустого места. Из оставшися VARCHAR типом вы выкинем всякие GUID телефоны адреса электронки и бизнесовые идентификаторы которые пробиты латиницей. ... Если взять БД какой-нибудь бухгалтерии, торговли и т.п. ERP, то текста там будет немного, не более 10%. ИМХО даже 10% это многовато, думаю в среднем 2-4%. Там гораздо острее стоит проблема GUID vs INT для ключей. Тут разница в 4 раза (16 и 4 байта). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 10:04 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Basil A. SidorovmaytonВерно?Да, я уже высказывался на эту тему. И продолжу высказываться, если сочту нужным: 1. Текст не является массивом символов 200% согласен. Я сам утверждаю что текст вообще никакой не массив а Stream<Char>. И работать с ним надо поточным образом. Если где-то мы нашли бизнес-сущность которая требует другой работы то это просто... не текст. Это как-раз и будет какой-то грёбаный массив. По остальным вашим поинтам. Я просто пытаюсь найти эти юзкейсы. Где. В comparison, collation? К каких частях строкового API находится функционал этих композитных символов? Я ок с aproach. Но я пока для себя не нахожу практического подтверждения. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 10:07 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
maytonИтого 328 знаков. Укладываемся в 9 битов. (не более 512 состоянии и еще запас есть)Очень плохо изобретать велосипеды, но ознакомившись в с тем, что уже сделано. Основные (если не все) европейские языки расположены в блоке из 2048 кодов. Это всего 11 бит. Полтора раза, если не жлобствовать и не занудствовать. Про "сжимающие" кодировки из ICU-репертуара я даже не стану упоминать. P.S. "Не сотвори себе кумира" - один пошёл по граблям и вы туда же. Используя правило 20/80 будем считать, что 20% данных имеют фиксированных размер, а 80% - "те самые пухнущие строки": Код: plaintext 1.
Просто потому, что положили на "банальную логику и элементарную эрудицию". ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 10:08 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
maytonНо до того как мы начали поиск суффикса в UTF8 - мы не знаем что внутри строки. Хотя упрощение - справедливое. Да.Нам пофигу, что внутри, если это UTF8. Не пофигу то, что мы ищем. А это нам известно. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 10:09 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Если речь о хранении, то можно использовать словарь символов: Код: sql 1.
Сами символы в словаре, а в хранилище только индексы. Если используется менее 256 символов, то один символ будет один байт независимо от языка(ов). Шутка ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 10:19 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Basil A. SidorovmaytonИтого 328 знаков. Укладываемся в 9 битов. (не более 512 состоянии и еще запас есть)Очень плохо изобретать велосипеды, но ознакомившись в с тем, что уже сделано. Основные (если не все) европейские языки расположены в блоке из 2048 кодов. Это всего 11 бит. Полтора раза, если не жлобствовать и не занудствовать. Про "сжимающие" кодировки из ICU-репертуара я даже не стану упоминать. P.S. "Не сотвори себе кумира" - один пошёл по граблям и вы туда же. Используя правило 20/80 будем считать, что 20% данных имеют фиксированных размер, а 80% - "те самые пухнущие строки": Код: plaintext 1.
Просто потому, что положили на "банальную логику и элементарную эрудицию". Это был brainstorm. Давайте закроем пока тему 9 бит. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 10:25 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Dima T, Если взять БД какой-нибудь бухгалтерии, торговли и т.п. ERP, то текста там будет немного, не более 10% Похоже, что это мнение человека, никогда не видевшего БД бухгалтерии, торговли, ERP и т. п. Я сам утверждаю что текст вообще никакой не массив а Stream<Char>. Поток это то, что мы не можем прочитать сразу, что не помещается в оперативную память, а лежит на внешнем устройстве. Такой смысл этого изначально. И вот у нас много оперативной памяти, но нас заставляют искусственно обращаться с ней, как с потоком. Это всего 11 бит. В UTF8 тратится 16. Да, неэффективно - я говорю о том же. Хреново сделали. что 20% данных имеют фиксированных размер, а 80% - "те самые пухнущие строки": Зачем фантазировать когда известно на практике, что как только начинаете мерять, на что тратится память, сразу на первом месте вылезут строки. И какая разница, фиксированный размер у них или нет? Они все равно вырастают в два раза. Сами символы в словаре, а в хранилище только индексы. Если используется менее 256 символов, то один символ будет один байт независимо от языка(ов). Шутка Это не шутка, и кодировка CP1251, например, является таким словарем. Нам нужно сохранить нижнюю половину таблицы полностью. Тоесть 128 симвлов оставить как есть. + 200 знаков для всех киррилических языков мира Нужно меньше на кириллицу и не обязательно в нижней половине таблицы оставлять как есть. Англосаксы же не подумали об остальных языках с умлаутами, когда делали свою кодовую таблицу. Включили свои символы и все. И когда переводят языки на латиницу, не озабочиваются придумыванием новых букв, используют те, что есть. В отличие от советских ученых, которым надо было показать оригинальность и самобытность чукчей или ненцев. В общем, русскую азбуку + может быть что то из славянских языков, в которых это сохраняется с древности, как умлауты в немецком. 100 не надо. бизнесовые идентификаторы которые пробиты латиницей. В России вообще то все должно быть на государственном языке - русском. Вообще все. Так что большинство строк в таблицах для российской бухгалтерии или ERP будут кириллическими. Если я ошибся или вы сомневаетесь то давайте мне вашу киррилическую базу и мы погоняем в ней Все строки в "моей" базе кириллические. То есть должны быть рассчитаны на хранение русских текстов. Я могу лишь проверить на досуге, сколько конкретно байт уходит на строки и сколько на все остальное. Тоесть масса служебной инфы кроме прикладной. Это только особенность JVM. RTTI в наше смутное время есть почти в каждом языке. А сколько собственно строк и каков их средний размер? Не считал, т. к. нужды не было. Я не принимаю этот аргумент. Где justification? Документация? Фрагмент кода? Очевидно же, что добавляется предварительный анализ каждого очередного байта, и склеивание их между собой в случае необходимости. Да, это не сложно. Но тем менее это придется делать. Это просто прекрасно! Из этого можно сделать вывод что не стоит использовать русский язык. Боюсь, что к этому и ведут. Потом развернут компанию - русский язык плохо хранится на компьютерах, давайте переходить на латиницу, мол. Я - же хочу числовую оценку. А вы просто сообщаете банальность. А что мне еще сказать? Для чисто русских текстов - в два раза. Тоже банальность. Именно от чего-то такого и отказались, когда придумали Unicode. Напрасно. ваша идея означает существенное увеличение сложности (т.е. потери производительности) ценой некоторого сокращения объема хранимых данных. Скажите, пожалуйста, откуда появляется увеличение сложности и падение производительности по сравнению с обработкой utf-8. Об организационной стороне вашей идеи даже думать не хочется :) Не вижу проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 10:53 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene NewА сколько собственно строк и каков их средний размер? Не считал, т. к. нужды не было. Я заметил что у вас вообще нет числовых оценок. Все на словах. Вы очертили проблему. Отлично. Я вам задаю встречный вопрос. Сколько? Дорогой мой Евгений? Сколько в вашей базе всех символов? И сколько из них - киррилических? И приложении. Жду. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 11:12 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene New, а что делать с иностранными названиями комплектующих в русскоязычных БД ? ведь это не обязательно инглишъ. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 11:36 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
mayton, Ок, я в базе посчитаю, когда найду время этим заняться. Еще раз замечу, что все, абсолютно все строковые поля в реляционной базе нужно расширять в 2 раза. Чтобы иметь гарантию, что туда поместится нужное число русских букв. Кстати, думаю, что для немцев и прочих западноевропейцев весь этот уникод выглядит совсем не так, как для нас. У них это, скорее всего, основная масса однобайтовых символов латиницы с редкими вкраплениями экзотических умлаутов. О увеличении объема в два раза в таком случае речи не идет. Выходит, что с русским языком поступили по-хамски, совершенно игнорируя наши интересы, и это хамство заслуживает наказания. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 11:36 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene NewИ когда переводят языки на латиницу, не озабочиваются придумыванием новых букв, используют те, что есть. В отличие от советских ученых, которым надо было показать оригинальность и самобытность чукчей или ненцев. И то, и другое — заблуждение. Точнее, для латиницы уже придумано столько дополнительных букв, что хватает для большинства новописьменных языков, хотя есть и недавние примеры изобретения знаков. С кириллицей та же история. Eugene NewВ общем, русскую азбуку + может быть что то из славянских языков, в которых это сохраняется с древности, как умлауты в немецком. 100 не надо. Почему для русского языка нужен алфавит, адекватно отражающий его фонетику, а для других — нет? Ваши идейные предшественники уже сэкономили на разработке шрифтов, когда сделали письменность для части северокавказских языков с триграфами вроде къь . Eugene NewВ России вообще то все должно быть на государственном языке - русском. Вообще все. Закон «О языках народов Российской Федерации» считает иначе. Eugene NewЫ2ваша идея означает существенное увеличение сложности (т.е. потери производительности) ценой некоторого сокращения объема хранимых данных. Скажите, пожалуйста, откуда появляется увеличение сложности и падение производительности по сравнению с обработкой utf-8. Ко всему тому, что уже есть для обработки теста, добавляется ловля ваших признаков смены кодировки и идентификаторов, что заодно губит на корню вашу же идею иметь строку как массив символов. Eugene Newзаслуживает наказания Так и написали бы сразу, что вам нужна маленькая победоносная война. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 14:43 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene NewВыходит, что с русским языком поступили по-хамски, совершенно игнорируя наши интересы, и это хамство заслуживает наказания. Вы вроде-бы поните "эпоху доткомов". Слышали про "Оберон". Делаю вывод что вы не школьник а чел среднего возраста. Но иногда от вас звучат совсем уж простите детские заявления и прокламации. Кого собираетесь наказать? И как? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 15:19 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene NewПоток это то, что мы не можем прочитать сразу, что не помещается в оперативную память, а лежит на внешнем устройстве. Такой смысл этого изначально. И вот у нас много оперативной памяти, но нас заставляют искусственно обращаться с ней, как с потоком. Все программирование построено на ограничениях. Поточная обработка информации - это один из важных принципов экономного обращения с ресурсами. Накопители последовательного доступа - потоковые. Потоковые операции взяты в основу коммуникаций. TCP протколоы. Pipelines Unix. Фундаметнальная структура данных Lisp - это не массив. Это список. Однонаправленный. Тоесть интерфейс - поток. Потоки - файлы. Потоковая обработка файла создает мягкую нагрузку на диск с высоким throughput. Очень многие интерфейсы доступа к архива Zip/Gzip - суть потоки. Потоки - курсоры баз данных. Потоки - шаблоны обработки данных в технологиях BigData. Самые топовые методологии обработки данных в функциональном программировании - тоже потоковые. +Они еще накладываеют контракт иммутабельности. Вернуть из функции поток всегда проще чем массив. В базах данные 1 раз прочиатть - это удачный кейс. Нет repeatable read. Нет доп накладных расходов. Если ваш курсор читает все строки выборки 1 раз это хороший план оптимизатора. И если вы откажетесь от идеи рандомного доступа ко всему всегда и везде - вдруг окается что многие контракты легче соблюдать. Окажется что многое ПО стыкуется легче. И на разрядность символа плевать. В будущем железо будет усложнятся в сторону эдакой себе пирамиды технологий. И random-access по памяти например может вызвать задержки более значимые чем сегодня. Памяти будет много. Терабайты и более но со своей спецификой. Предсказатели переходов и кеши будут соптимизированы на упреждающую выборку. Тоесть - читаете байт - предсказание что будете читать еще сто тыщ мегабайт после него. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 16:33 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
exp98, что делать с иностранными названиями комплектующих в русскоязычных БД ? Писать по-русски. Если это продается или покупается в Российской Федерации, оно обязано иметь русское название. Иначе вы его в счет-фактуру записать не сможете. Т. к. весь документооборот ведется на русском языке. Посчитал поля одной БД. Индексы не считал, как не учитывал и прочие технические детали. Просто размер поля * число строк в таблице. Вышло, что строки занимают 39% от всех. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 17:54 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Но вы можете в БД хранить в отдельных полях названия хоть на суахили, если вам это надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 17:55 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene NewНо вы можете в БД хранить в отдельных полях названия хоть на суахили, если вам это надо. ...в однобайтовой кодировке и ни в коем случае их не обрабатывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 18:10 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
И если вы откажетесь от идеи рандомного доступа ко всему всегда и везде - вдруг окается что многие контракты легче соблюдать. Жили давно в хрущевке. Потом переехали во дворец площадью 2000 кв. м. Но стали всю ставить стены и перегородки, чтобы ни одно помещение не было большим и забивать их вещами, хламом, навозом с улицы. В итоге оказалось, что места осталось еще меньше чем раньше и все стало еще неудобнее, т. к. на кухню площадью те же 4 кв. метра теперь надо ходить на третий этаж по коридору, а спускаться обратно по веревочной лестнице. В будущем железо будет усложнятся в сторону эдакой себе пирамиды технологий. Судя по искуственному усложнению софта, когда то, что раньше занимало в 1000 раз меньше места и работало лучше, теперь представляет из себя некоего монстра, можно поверить и в искусственное усложнение железа. Но является ли это правильным? Нет. Это будет именно искусственное усложнение, так как технический прогресс в этой области уже остановился. Сейчас такое время, что берут технологии 1970-х и выдают их за великий прорыв. Кого собираетесь наказать? И как? Я сказал, что они заслуживают наказания. Заслуживают. Накажем их для начала презрением и неприятием. Точнее, для латиницы уже придумано столько дополнительных букв, что хватает для большинства новописьменных языков Тупо лепят стандартный латинский алфавит и все. Не хватало им еще этих заморочек. У них вообще распространенное выражение "speak human" - то есть всего один язык считается человеческим - английский. Приравнивание кириллицы и великого русского языка к языкам отсталых народностей, не имевших даже письменности - это сильное унижение русского языка и его носителей. Вы же тоже по-русски говорите. Вам это зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 18:33 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Забавный факт - латиница не приспособлена для английского языка! В нем для некоторых звуков требуется сочетание букв и большинство слов не произносится так, как пишется. Запись слова на английском вообще имеет слабую связь с его произношением. Русский язык в этом плане намного лучше. Вы можете читать слова так, как они написано. Стандартной кириллицей можно записать больше звуков, чем латиницей. На фоне этого придумывание новых букв для ньюансов произношения каких-то звуков выглядит искуственным. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 19:03 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
О языках народов Российской Федерации Поскольку нигде нет списка т. н. народов Российской Федерации, отсутствует объект для применения этого закона. Зато есть есть закон о государственном языке России И давайте больше не будем отклоняться от основной темы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 19:15 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Так я дал же числовую оценку. 21688419 Посчитал поля одной БД. Индексы не считал, как не учитывал и прочие технические детали. Просто размер поля * число строк в таблице. Вышло, что строки занимают 39% от всех. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 20:15 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene NewТак я дал же числовую оценку. 21688419 Посчитал поля одной БД. Индексы не считал, как не учитывал и прочие технические детали. Просто размер поля * число строк в таблице. Вышло, что строки занимают 39% от всех. Размер поля умнижил на число строк? Это - туфта. Я тебе подсказал SQL-шаблон. У тебя должен быть sum, length в запросе. Пересчитай по честному. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 20:19 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
mayton, насколько я понимаю, вы хорошо знаете Oracle. расскажите мне, пожалуйста, как Oracle хранит записи и почему для varchar(100) не выделяется всегда 100 символов. Если окажется, что я глубоко заблуждался, посыплю голову пеплом и уйду с форума учить матчасть. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 21:09 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene Newmayton, насколько я понимаю, вы хорошо знаете Oracle. расскажите мне, пожалуйста, как Oracle хранит записи и почему для varchar(100) не выделяется всегда 100 символов. Если окажется, что я глубоко заблуждался, посыплю голову пеплом и уйду с форума учить матчасть. В нашей задаче нет необходимости изучать бинарный формат хранения данных Oracle. Просто поверьте мне что современные СУБД (и MSSQL, и PostgreSQL) используют плавающий размер строки. отличный от DBase/FoxPro. В этом можно убедится если создать пустую таблицу и наполнить ее данными и померять размер по USER_SEGMENTS. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 22:04 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Не использовал я Oracle. В блоках оно хранит и сколько надо. Теперь понятно, отчего вас не так беспокоят лишние затраты памяти. Причем это обычный подход для современных СУБД. Даже интересно стало этот Oracle покрутить, посмотреть как в нем с таким подходом дела с обновлениями строковых данных обстоят. Не сказать, чтобы это обнулило все, что я говорил - это не так. Но оплеуху я неплохую получил. Пойду пеплом голову посыпать.. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 22:06 |
|
Юникод и utf8
|
|||
---|---|---|---|
#18+
Eugene NewНе использовал я Oracle. В блоках оно хранит и сколько надо. Теперь понятно, отчего вас не так беспокоят лишние затраты памяти. Причем это обычный подход для современных СУБД. Даже интересно стало этот Oracle покрутить, посмотреть как в нем с таким подходом дела с обновлениями строковых данных обстоят. Покрути. Поищи редактор BBED. Он вроде позволяет бинари просматривать. За советами - ходи сюда . К очень дружелюбным и отзывчивым ДБА. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2018, 22:11 |
|
|
start [/forum/moderation_log.php?user_name=new1024]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
175ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 725ms |
total: | 1027ms |
0 / 0 |