Господа! Недавно сел создавать базу в MS SQL и обнаружил что в нем отсутсвует тип BOOL. Так же несколько обескуражило отсутствие BEFORE триггеров. Расскажите как мне теперь жить с этим... А тенденция к улучшению ситуации наблюдается? И когда нас настигнет светлое будущее????
Здравствуйте, Silk, Вы писали:
S>Господа! Недавно сел создавать базу в MS SQL и обнаружил что в нем отсутсвует тип BOOL.
tinyint попробуйте S> Так же несколько обескуражило отсутствие BEFORE триггеров.
Зато есть INSTEAD OF
CREATE TRIGGER trigger_name
ON { table | view }
[ WITH ENCRYPTION ]
{
{ { FOR | AFTER | INSTEAD OF } { [ INSERT ] [ , ] [ UPDATE ] }
[ WITH APPEND ]
[ NOT FOR REPLICATION ]
AS
[ { IF UPDATE ( column )
[ { AND | OR } UPDATE ( column ) ]
[ ...n ]
| IF ( COLUMNS_UPDATED ( ) { bitwise_operator } updated_bitmask )
{ comparison_operator } column_bitmask [ ...n ]
} ]
sql_statement [ ...n ]
}
Здравствуйте, KGP, Вы писали:
KGP>Здравствуйте, Silk, Вы писали:
S>>Господа! Недавно сел создавать базу в MS SQL и обнаружил что в нем отсутсвует тип BOOL. KGP>tinyint попробуйте
ИМХО, лучше bit все же
S>> Так же несколько обескуражило отсутствие BEFORE триггеров. KGP>Зато есть INSTEAD OF
Здравствуйте, bralgin, Вы писали:
S>>>Господа! Недавно сел создавать базу в MS SQL и обнаружил что в нем отсутсвует тип BOOL. KGP>>tinyint попробуйте B>ИМХО, лучше bit все же
а чего ? экономия, что ли ...
[msdn]Columns of type bit cannot have indexes on them.
Microsoft® SQL Server™ optimizes the storage used for bit columns. If there are 8 or fewer bit columns in a table, the columns are stored as 1 byte. If there are from 9 through 16 bit columns, they are stored as 2 bytes, and so on.[/msdn]
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, romashka, Вы писали:
S>>>Господа! Недавно сел создавать базу в MS SQL и обнаружил что в нем отсутсвует тип BOOL. R>>Используй bit
А>Кста, если планируешь поддержку Access, то не советую использовать Bit. В Акцессе true имеет значение "-1", что несколько конфузит...
Да не конфузит — во многих продуктах так. Просто булевый тип обычно целое число:
0x0000 — false,
not 0x0000 = 0xFFFF — true. Где not — битовая инверсия
т.е. 0xFFFF это -1 в знаковом представлении, в беззнаковом 65636. Вобщем исходить надо из того, что true — любое число отличное от нуля.
Здравствуйте, bralgin, Вы писали:
B>Здравствуйте, KGP, Вы писали:
KGP>>Здравствуйте, Silk, Вы писали:
S>>>Господа! Недавно сел создавать базу в MS SQL и обнаружил что в нем отсутсвует тип BOOL. KGP>>tinyint попробуйте B>ИМХО, лучше bit все же
По мне так тоже. Но! Только если не планируется индексов по столбцу — тогда tinyint
S>>> Так же несколько обескуражило отсутствие BEFORE триггеров. KGP>>Зато есть INSTEAD OF B>
Здравствуйте, KGP, Вы писали:
KGP>Здравствуйте, Silk, Вы писали:
S>>Господа! Недавно сел создавать базу в MS SQL и обнаружил что в нем отсутсвует тип BOOL. KGP>tinyint попробуйте
Насколько я понимаю TSQL начисто лишен синтаксического сахара. Где все сделано по принципу: "если синтаксическую конструкцию можно заменить набором из каких-либо других — то она не нужна"
S>> Так же несколько обескуражило отсутствие BEFORE триггеров. KGP>Зато есть INSTEAD OF
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, KGP, Вы писали:
KGP>>Здравствуйте, Silk, Вы писали:
S>>>Господа! Недавно сел создавать базу в MS SQL и обнаружил что в нем отсутсвует тип BOOL. KGP>>tinyint попробуйте
TinyInt, Bit, VARCHAR(1) со значениями 'T' или 'F', это конечно все понятно, но!
Table.Field = True;
или
Table.Field = -1;
Table.Field = ~0; // ????
___>Насколько я понимаю TSQL начисто лишен синтаксического сахара. Где все сделано по принципу: "если синтаксическую конструкцию можно заменить набором из каких-либо других — то она не нужна"
S>>> Так же несколько обескуражило отсутствие BEFORE триггеров. KGP>>Зато есть INSTEAD OF
___>"Да, это уж будет посильнее Фауста Гетте"
И с INSTEAD OF то же самое. А что до сахара — вы всегда сможете съесть ваш обед руками. Ну максимум вам понадобится ложка. Так зачем же вам все остальные приборы?
На вопросы свои ответы я получил. Большое всем спасибо.
S>И с INSTEAD OF то же самое. А что до сахара — вы всегда сможете съесть ваш обед руками. Ну максимум вам понадобится ложка. Так зачем же вам все остальные приборы?
Да от лукавого они — если не выеживаться перед кем-то в ресторане — ложки хватает на все. Ну а японцы, корейцы и т.п. вообще обходятся двумя палочками.
Здравствуйте, Lexey, Вы писали:
L>Оно может быть в индексе. Но индекс не может состоять ТОЛЬКО из битового поля.
Вы знаете ... у меня MS SQL Server 2000 и он не даёт ни только PRIMARY KEY сделать из
нескольких полей + поле bit ... но и вообще сказано, что bit не может быть в индексе ...
а с учетом того, как записываются значения из bit ... это вполне объяснимо
[msdn]Columns of type bit cannot have indexes on them.
Microsoft® SQL Server™ optimizes the storage used for bit columns. If there are 8 or fewer bit columns in a table, the columns are stored as 1 byte. If there are from 9 through 16 bit columns, they are stored as 2 bytes, and so on.
[/msdn]
Здравствуйте, KGP, Вы писали:
L>>Оно может быть в индексе. Но индекс не может состоять ТОЛЬКО из битового поля. KGP>Вы знаете ... у меня MS SQL Server 2000 и он не даёт ни только PRIMARY KEY сделать из KGP>нескольких полей + поле bit ... но и вообще сказано, что bit не может быть в индексе ...
Насчет PK не знаю, не пробовал. А вот в обычном индексе бит может спокойно присутствовать. Пару раз такие индексы доводилось строить.
KGP>а с учетом того, как записываются значения из bit ... это вполне объяснимо
KGP>[msdn]Columns of type bit cannot have indexes on them.
Здравствуйте, _d_m_, Вы писали:
KGP>>>tinyint попробуйте B>>ИМХО, лучше bit все же ___>По мне так тоже. Но! Только если не планируется индексов по столбцу — тогда tinyint
Индекс по одному булевому полю бессмысленен в большинстве случаев. Как уже сказали, селективность у него почти никакая? и по поиск по нему по стоимости будет слабо отличаться от table scan.
Здравствуйте, KGP, Вы писали:
KGP>а с учетом того, как записываются значения из bit ... это вполне объяснимо
Да, объяснимо для кластерного индекса, но не для обычного.
KGP>Microsoft® SQL Server™ optimizes the storage used for bit columns. If there are 8 or fewer bit columns in a table, the columns are stored as 1 byte. If there are from 9 through 16 bit columns, they are stored as 2 bytes, and so on. KGP>[/msdn]
К обычному индексу это никакого отношения иметь не будет — значение поля в нем дублирует значение в таблице, и расположить его можно как угодно.
Здравствуйте, Lexey, Вы писали:
L>К обычному индексу это никакого отношения иметь не будет — значение поля в нем дублирует значение в таблице, и расположить его можно как угодно.
нет проблем — скрипт по созданию таблицы с полем bit и индексом, включающем его — в студию !
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, _d_m_, Вы писали:
KGP>>>>tinyint попробуйте B>>>ИМХО, лучше bit все же ___>>По мне так тоже. Но! Только если не планируется индексов по столбцу — тогда tinyint
L>Индекс по одному булевому полю бессмысленен в большинстве случаев. Как уже сказали, селективность у него почти никакая? и по поиск по нему по стоимости будет слабо отличаться от table scan.
Здравствуйте, KGP, Вы писали:
L>>К обычному индексу это никакого отношения иметь не будет — значение поля в нем дублирует значение в таблице, и расположить его можно как угодно.
KGP>нет проблем — скрипт по созданию таблицы с полем bit и индексом, включающем его — в студию !
Зря смайлы ставишь. Скрипт я тебе генерировать не буду — сам справишься.
Чтобы пропало неверие почитай SYMPTOMS в статейке за номером 824018 из MS KB.
Здравствуйте, Lexey, Вы писали:
L>Зря смайлы ставишь. Скрипт я тебе генерировать не буду — сам справишься. L>Чтобы пропало неверие почитай SYMPTOMS в статейке за номером 824018 из MS KB.
Точно, можно SQL ... сорри, просто доверял EM, который напрочь отказывался даже простой индекс сделать.
Так же несколько обескуражило отсутствие BEFORE триггеров. Расскажите как мне теперь жить с этим... А тенденция к улучшению ситуации наблюдается? И когда нас настигнет светлое будущее????
