Oracle10g на Линухе - быстрее всех!

[verzlo]

Вот случайно набрел...
http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... egory=3773

Надо же.. кто-то покупает небось....

[zVlad]

......
zVlad, ну что Вас непрерывно тянет на какие-то застольные разговоры, только вместо "ты меня уважаешь?" у Вас каждый раз всё скатывается к "ты что, IBM не уважаешь???" Ей-Богу я даже в нетрезвом виде стараюсь держаться подальше от таких бесед. Так что прошу прощения - я лучше на технические темы буду стараться высказываться.

Наверное это от моего рабоче-крестьянского происхожлдения .
Давно уже замечаю, что наличие разных там фичей в продукте (в данном случае в базах данных), равно как знание их тем кто рядом сидит и называется DBA, не гарантирует успеха бизнеса ради которого эта самая DB и DBA были куплены. Нет конечно, если купить (не буду говорить что) и посадить (не буду говорить кого) то тогда вообще может ничего не получиться. Но в среднем ни сильно навороченных RDBMS ни гениев не надо никому.
Вот возьмите мою контору, вот уже больше двух лет мы время от времени бъемся головой об не чувствительность к регистру символов SQL Server-a, до сего дня мне - тупому DB2 DBA - казалось это SQL Server такую особенность имеет, сегодня оказалось нет, это не особенность - это мощь SQl server-a, и это наши спецы так решили исходя из соображений производительности приложений, которые с другой стороны находятся. Может они и не до конца правы, кто ж их поимет - они по-русски то не говорят. Но я с ними спорить и докапываться не стану.

Так что мне на сегодня очень льстит "упрощенность" DB2 - я по крайне мере знаю (знал и раньше), что в ней нет излишеств, на которых можно погореть, или дураком выглядеть (уж я бы нашего SQL Server специалиста повозил бы рожей по стенке если бы он понимал по-нашему). Уж если не его, то менеджера, который принял решение реплицировать DB2 в SQL Server.

[Dmitry67]

То есть в случае CHAR не должно быть никаких акцентов - это коды, произвольные коды, которые могут сравниваться только как бинарные коды

Да ????
А я то наивный думал что CHAR - это символы
Ладно, забыли про case-sensitivity. Хоть ORDER BY то работать должен ?
Учитывая то только в англ языке алфавит compatible with ASCII. Ну еще по моему в интальянском потому что там букв мало.

Во всех остальных языках сортировка по ASCII неправильна ! Это означает что на всей территории Европы для сортировки нельзя использовать ORDER BY сервера а все эти "stupid' сортировки делать на клиенте. Вот уж действительно "без излишеств". Я бы даже сказал полный аскетизм

Только потом не надо удивляться почему DB2 считают 'чем то старым с mainframe' которое не поспевает за ходом прогресса

[Dmitry67]

1
Моя главная мысль (если отбросить все рассуждения о мудрости) была в том, что в данном контексте база данных должна сохранять то, что ее просят сохранить, и выполнять операции сравнения так это соответсвует здравому, не затуманеному смыслу -
2
т.е. согласно которому "б" не равен "Б", разве что после трех рюмок. Если же нужны особые правило - делай это через расширения - Extenders.

1 В режиме case_insensitive тем не менее сервер сохраняет и воспроизводит данные AS IS, не меняя регистра
Это вам надо сохранять НЕ as is с помощью upper. Кстати как upper работает для русского языка ?

2 Ага. А вы согласны что 'b' < 'c' < 'ç' < 'd' ???
Это я Вам как француз говорю. У нас алфавит такой. И несмотря на то что ç находится в старшей части таблицы ascii, даже после трех рюмок никто не поставит ç после z !

[zVlad]

............

Только потом не надо удивляться почему DB2 считают 'чем то старым с mainframe' которое не поспевает за ходом прогресса

А вот здесь, Дима, я Вас вынужден огорчить.
DB2 считают, как Вы сказали "...'чем то старым с mainframe' ...", только ограниченные люди, которые знаниям предпочитают слухи, распускаемые еще более ограниченными людьми.
Я уже намекал выше о том, что еще в 1993 (до появления SQL Server-a) мы совершенно спокойно, пользуясь руководством по Natuonal Language Support (NLS), обеспечили правильную сортировку и вообще использование киррилицы в SQL/DS (ныне DB2 for VM). И знаете как это делалось в SQL/DS? Нет не знаете. Делалось это путем перекодировки символов перед их сохранением и обратной перекодировки перед возвращением. Делается это естественно на сервере. Сравнения и сортировки осуществляются до обратной перекодировки. С помощью этого механизма можно любой алфавит обеспечить, даже придуманный произвольно. Я не могу Вам рассказать как с этим обстоят дела ныне, думаю что как то обстоят не хуже чем было. А как интересно это сделано в SQL Server?
Уверяю Вас, Дима, Вам станет легче жить если Вы поймете что DB2 - это современная база данных ничем не уступающая базам данных конкурентов ИБМ, и кое в чем даже их превосходящая.

[Dmitry67]

И знаете как это делалось в SQL/DS? Нет не знаете. Делалось это путем перекодировки символов перед их сохранением и обратной перекодировки перед возвращением. Делается это естественно на сервере. Сравнения и сортировки осуществляются до обратной перекодировки.

Ага, то есть таки то что Вы писали неверно:

То есть в случае CHAR не должно быть никаких акцентов - это коды, произвольные коды, которые могут сравниваться только как бинарные коды

А именно сравниваются таки не бинарные коды, а коды после перекодировки.

Что касается того что для буквы Й понадобилось писать программу на ассемблере то Вы пожалуйста никому этого не говорите а то как про ассемблер услышат то и не купят DB2.

И все таки, я хочу распечатать телефонную книгу

select Names from PhoneBook order by Name

теперь мне тоже самое надо сделать для French accent_insensitive sort order. Что мне надо изменить в операторе ?

[zVlad]

И знаете как это делалось в SQL/DS? Нет не знаете. Делалось это путем перекодировки символов перед их сохранением и обратной перекодировки перед возвращением. Делается это естественно на сервере. Сравнения и сортировки осуществляются до обратной перекодировки.

Ага, то есть таки то что Вы писали неверно:

То есть в случае CHAR не должно быть никаких акцентов - это коды, произвольные коды, которые могут сравниваться только как бинарные коды

А именно сравниваются таки не бинарные коды, а коды после перекодировки.

Что касается того что для буквы Й понадобилось писать программу на ассемблере то Вы пожалуйста никому этого не говорите а то как про ассемблер услышат то и не купят DB2.

И все таки, я хочу распечатать телефонную книгу

select Names from PhoneBook order by Name

теперь мне тоже самое надо сделать для French accent_insensitive sort order. Что мне надо изменить в операторе ?

DB2 compares codes without having to decode them. Decoding and encoding is an optional for now. Now, if you wish to run say Cyrillic (or French) you have to set up code page in DB2 properly that's all.
You are still able to write Assembler for aka FEILDPROC if you need special handling, for example, when you deal with phone book (see cut from DB2 docs below).
Below you can find few cuts from DB2 docs (sorry for formats) related to discussed problems. Please, read and give your opinion.


==========================================================

│ │
│ │
│ >───┬─UCASE─┬─(expression)───────────────────────────────────────────> │
│ └─UPPER─┘ │
│ │
│ │
└────────────────────────────────────────────────────────────────────────┘

The schema is SYSIBM.

The UCASE or UPPER function returns a string in which all the characters have been
converted to uppercase characters.

expression
An expression that specifies the string to be converted. The string must be a
character or graphic string. A character string argument must not be a CLOB and must
have an actual length that is not greater than 255. A graphic string argument must not
be a DBCLOB and must have an actual length that is not greater than 127.


The alphabetic characters of the argument are translated to uppercase characters
based on the value of the LC_CTYPE locale in effect for the statement. For example,
characters a-z are translated to A-Z, and characters with diacritical marks are
translated to their uppercase equivalent, if any. The locale is determined by special
register CURRENT LOCALE LC_CTYPE. For information about the special register, see
"CURRENT LOCALE LC_CTYPE" in topic 3.14.4.

If the LC_CTYPE locale is blank when the function is executed, the result of the function
depends on the data type of expression. For a character string expression, characters
a-z are translated to A-Z and characters with diacritical marks are not translated. For a
graphic string expression, an error occurs.

The length attribute, data type, subtype, and CCSID of the result are the same as the
expression. If the argument can be null, the result can be null; if the argument is null, the
result is the null value.

============================================================
3.14.4 CURRENT LOCALE LC_CTYPE

CURRENT LOCALE LC_CTYPE specifies the LC_CTYPE locale that will be used to
execute SQL statements that use a built-in function that references a locale. Functions
LCASE, UCASE, and TRANSLATE (with a single argument) refer to the locale when they
are executed. The data type is CHAR(50). If necessary, the value is padded on the right
with blanks so that its length is 50 bytes.

The initial value of CURRENT LOCALE LC_CTYPE is determined by the value of field
LOCALE LC_CTYPE on installation panel DSNTIPF. The default for the initial value of that
field is blank unless your installation has changed the value of that field. The initial value
of CURRENT LOCALE LC_CTYPE in a stored procedure or user-defined function is
inherited from the invoker.

You can change the value of the register by executing the statement SET CURRENT
LOCALE LC_CTYPE. For details about this statement, see "SET CURRENT LOCALE
LC_CTYPE" in topic 6.91.

Example: Save the value of current register CURRENT LOCALE LC_CTYPE in host
variable HV1, which is defined as VARCHAR(50).

EXEC SQL VALUES(CURRENT LOCALE LC_CTYPE) INTO :HV1;

============================================================

APPENDIX1.1.3 Specifying locales

Rules for uppercase and lowercase usage vary according to language and country. A locale defines the subset of a user's environment that depends on language and cultural conventions.
DB2 uses the information associated with a locale to execute UPPER, LOWER, and TRANSLATE functions in a culturally correct manner. A locale consists of two components: the first component represents a specific language and country, and the second component is a CCSID.

Example: In the locale, Fr_CA.IBM-1047, Fr_CA represents the language and country (French Canadian), and IBM-1047 is the associated CCSID.

The symbol for Euro currency is supported through the modifier @EURO.

Example: To display results in Euro dollars instead of French Francs, specify Fr_FR@EURO.

Table 124 shows a partial list of locales supplied with OS/390 C/C++. For a more complete list of
locales, see OS/390 C/C++ Programming Guide.

=======================================================

APPENDIX1.1.4.1 How an entry in SYSIBM.SYSSTRINGS works

The catalog table SYSIBM.SYSSTRINGS contains the following columns:

INCCSID The source CCSID of a character conversion.

OUTCCSID The target CCSID of a character conversion.

TRANSTYPE The type of conversion:

SS SBCS data to SBCS data
SM SBCS data to EBCDIC MIXED data
MS EBCDIC MIXED data to SBCS (EBCDIC and ASCII) data
PS ASCII MIXED data to SBCS (EBCDIC and ASCII) data
GG GRAPHIC data to GRAPHIC data
PM ASCII MIXED data to EBCDIC MIXED data
MM EBCDIC MIXED data to EBCDIC MIXED data.
MP EBCDIC MIXED to ASCII MIXED data.
PP ASCII MIXED to ASCII MIXED data.
SP SBCS (ASCII and EBCDIC) to ASCII MIXED data.

ERRORBYTE Specifies the byte used in the conversion table (TRANSTAB) as an error indicator.
For example, if ERRORBYTE is X'3E', that byte is used in the conversion table to indicate
that no conversion is defined for code points that map to X'3E'. Null indicates the absence
of an error indicator.

SUBBYTE Specifies the byte used in the conversion table (TRANSTAB) as a substitution
character. For example, if SUBBYTE is X'3F', that byte is used in the conversion table as a
substitute for code points that map to X'3F'. A warning occurs when a code point maps to
the value of SUBBYTE. Null indicates the absence of a substitution character.

TRANSPROC The name of a module or a blank string. If IBMREQD is N, a non-blank value of
TRANSPROC is the name of a user-provided conversion procedure. If IBMREQD is Y, a
non-blank value of TRANSPROC is the name of a DB2 module that contains DBCS
conversion tables.

IBMREQD Y indicates that the row is provided by IBM. N indicates that the row has been
inserted by the user.

TRANSTAB A 256-byte conversion table or an empty string.


Each row of SYSSTRINGS contains information about the conversion of character strings from the
coded character set identified by INCCSID to the coded character set identified by OUTCCSID. The
conversion function is automatically invoked when a conversion from the coded character set
identified by the INCCSID column to the coded character set identified by the OUTCCSID column is
required.

For example, the row of SYSSTRINGS in which the value of INCCSID is 500 and the value of
OUTCCSID is 37 describes the conversion from CCSID 500 to CCSID 37. The row in which the
value of INCCSID is 37 and the value of OUTCCSID is 500 describes the conversion from CCSID 37
to CCSID 500.

=========================================================

APPENDIX1.2.7 Field procedures

Field procedures are assigned to a table by the FIELDPROC clause of CREATE TABLE and
ALTER TABLE. A field procedure is a user-written exit routine to transform values in a
single short-string column. When values in the column are changed, or new values
inserted, the field procedure is invoked for each value, and can transform that value
(encode it) in any way. The encoded value is then stored. When values are retrieved
from the column, the field procedure is invoked for each value, which is encoded, and
must decode it back to the original string value.

Any indexes, including partitioned indexes, defined on a column that uses a field
procedure are built with encoded values. For a partitioned index, the encoded value of the
limit key is put into the LIMITKEY column of the SYSINDEXPART table. Hence, a field
procedure might be used to alter the sorting sequence of values entered in a column. For
example, telephone directories sometimes require that names like "McCabe" and
"MacCabe" appear next to each other, an effect that the standard EBCDIC sorting
sequence does not provide. And languages that do not use the Roman alphabet have
similar requirements. However, if a column is provided with a suitable field procedure, it
can be correctly ordered by ORDER BY.
........................
==========================================================

[Dmitry67]

Спасибо, zVlad, я понял
Я был неправ когда написал про отсутствие языковой поддержки DB2
В DB2 есть тки collation (они называются code pages)
Я не смог понять могут ли разные базы таблицы и колонки иметь разные code pages или это возможно только для сервера целиком
Возможно писать сови функци для encode/decode, однако требование наличия функции decode приводит невозможности существования case-insensitive collations, то есть любых collations с потерей информации
SQL server всегда хранит данные as is, а испльзует 'encode' функцию только на лету. То есть если сравниваются строки A и B То на самом деле сравниваются encode(A) vs encode(B)
Encoded значение не хранится и потому отпадает необходимость в функции decode

P.S
А что длина varchar ограничена 255 ?

[zVlad]

Спасибо, zVlad, я понял
Я был неправ когда написал про отсутствие языковой поддержки DB2
В DB2 есть тки collation (они называются code pages)
Я не смог понять могут ли разные базы таблицы и колонки иметь разные code pages или это возможно только для сервера целиком
Возможно писать сови функци для encode/decode, однако требование наличия функции decode приводит невозможности существования case-insensitive collations, то есть любых collations с потерей информации
SQL server всегда хранит данные as is, а испльзует 'encode' функцию только на лету. То есть если сравниваются строки A и B То на самом деле сравниваются encode(A) vs encode(B)
Encoded значение не хранится и потому отпадает необходимость в функции decode

P.S
А что длина varchar ограничена 255 ?

Code page is serverwise setting. Prior to DB2 ver. 7 two code pages are allowed to be on server: one for ASCII, and one for EBCDIC.
By the way what about EBCDIC on MS SQL?
Begins from ver. 7 UNICODE is available in DB2.
Varchar could be up to 32704. Datatype CHAR has limit 255.

P.S. What happen when Client has code page different than Server. For example, client has CP866 (OS/2, or PC DOS), and SQL Server has CP1251?

[SVK]

zVlad, а зачем такие цитаты???? На сайте IBM все это есть структурированное, с индексами и поиском, в форматах HTML и PDF.... Не проще дать ссылку?

[Dmitry67]

1
Code page is serverwise setting. Prior to DB2 ver. 7 two code pages are allowed to be on server: one for ASCII, and one for EBCDIC.

2
By the way what about EBCDIC on MS SQL?

3 What happen when Client has code page different than Server. For example, client has CP866 (OS/2, or PC DOS), and SQL Server has CP1251?

1 Плохо конечно что в сервере нельзя иметь двух кодовых страниц
Это часто бывает важно
Представьте например нидерландско французскую фирму

2 Пдерживается
Для EBCDIC есть набор collation

3 Это вопрос сложный
Если совру то старшие товарищи меня поправят

unicode client читающий unicode data через современный интерфейс всегда читает нормально
unicode client читающий varchar (nonunicode) получит данные всегда нормально потому что сервер имеет информацию о collation колонки и значит может корректно преобрзовать к unicode
nonunicode client или если испьуются старые интерфейсы типа dblib может потерять информацию о collation. Тогда будет использована codepage клиента

[tengiz]

nonunicode client или если испьуются старые интерфейсы типа dblib может потерять информацию о collation. Тогда будет использована codepage клиента

Хороший клиент сделает преобразование из server codepage в unicode а затем из unicode в client codepage или наоборот, когда данные идут от клиента к серверу (например, так делается в bcp / bulk insert). Это самый общий вид преобразования. Возможны варианты, оптимизирующие прямые преобразования из одной кодовой страницы в дргугую. Но в любом случае, такие преобразования никогда не гарантируются - всегда нужно быть готовыми к искажению данных, так как символы и коды, разрешённые в двух разных кодовых страницах, необязательно имеются в обеих.

[zVlad]

Казалось бы ну что можно нового узнать о хранении символьных данных. Ан нет. В дополнение к тому что я здесь сообщал о хранении символьных данных в DB2, о лишь кодовых страницах одной для ASCII и вторая для EBCDIC (UNICODE опускаем для ясности). Кроме того у DB2 имеется три режима для символьных данных (SVK, я привожу цитаты прямо в тексте поскольку для людей не пользующихся ИБМ документацией ежедневно это может быть затруднительно, да и не интересно обращаться к докум непосредственно. Тем не менее для более любознательных:
http://publib.boulder.ibm.com/infocenter/db2help ):

FOR subtype DATA
Specifies a subtype for a character string column, which is a column with a data type of CHAR,
VARCHAR, LONG VARCHAR, or CLOB. Do not use the FOR DATA clause with columns of any other
data type (including any distinct type). subtype can be one of the following:

SBCS
Column holds single-byte data.

MIXED
Column holds mixed data. Do not specify MIXED if the value of field MIXED DATA on installation
panel DSNTIPF is NO.

BIT
Column holds BIT data. Do not specify BIT for a CLOB column.

If you do not specify the FOR clause, the column is defined with a default subtype. The default is
SBCS when the value of field MIXED DATA on installation panel DSNTIPF is NO. The default is MIXED when the value is YES.


При этом MIXED YES|NO в инсталяции означает:

Specify whether the code points X'0E' and X'0F' have special meaning as the shift-out and shift-in controls for
character strings that include double-byte characters.

 NO indicates that these code points have no special meaning. Therefore, all character strings are single-byte
character set (SBCS) data.

 YES indicates that these code points have the special meaning described above. Therefore, character strings
can be SBCS or MIXED data.

[zVlad]

nonunicode client или если испьуются старые интерфейсы типа dblib может потерять информацию о collation. Тогда будет использована codepage клиента

Хороший клиент сделает преобразование из server codepage в unicode а затем из unicode в client codepage или наоборот, когда данные идут от клиента к серверу (например, так делается в bcp / bulk insert). Это самый общий вид преобразования. Возможны варианты, оптимизирующие прямые преобразования из одной кодовой страницы в дргугую. Но в любом случае, такие преобразования никогда не гарантируются - всегда нужно быть готовыми к искажению данных, так как символы и коды, разрешённые в двух разных кодовых страницах, необязательно имеются в обеих.

Подавляющему числу применений баз данных UNICODE не нужен и не будет нужен еще долго. Нормальная же дисциплина общения сервера с клиентом нужна всегда. И такой дисциплиной может быть (как это есть в случае DB2) посылка намера кодовой страницы вместе с данными запрашивающей (или принимающей стороне) с последующей трансляцией данных если это допустимо без искажений (или с допустимыми и наперед известными т.е. согласованными искажениями) или отказом и сообщением об ошибке. Таким образом, на мой взгляд, клиент (как впрочем и сервер) могут быть правильными и неправильными, но не "хорошими" и (видимо) "не хорошими".

Кстати, какие будут предложения по решению такой проблемы: мы не знаем наперед с какими кодовыми страницами работают наши клиенты? UNICODE? А если клиент не знает UNICODE?

[Dmitry67]

1
Подавляющему числу применений баз данных UNICODE не нужен и не будет нужен еще долго.

2
И такой дисциплиной может быть (как это есть в случае DB2) посылка намера кодовой страницы вместе с данными запрашивающей (или принимающей стороне) с последующей трансляцией данных если это допустимо без искажений

3
Кстати, какие будут предложения по решению такой проблемы: мы не знаем наперед с какими кодовыми страницами работают наши клиенты? UNICODE? А если клиент не знает UNICODE?

1 Я не согласен
Действительно, хранить unicode в базе когда это реально не нужно - расточительство
Во всех остальных случаях должен быть UNICODE
Пишущий сейчас неunicode клиента подобен пишущему под Win16

2 Так делает MS SQL базируясь на collation колонки

3 Опять. Клиента НАДО писать на UNICODE