Пользуясь случаем поздравляю всех с наступающим Рождеством!
Также имеется вопрос: у меня есть домен
... VARCHAR(100) CHARACTER SET WIN1251 COLLATE WIN1251
мне надо получить
... VARCHAR(100) CHARACTER SET WIN1251 COLLATE PXW_CYRL
команда
ALTER DOMAIN "ShortVarchar"
TYPE VARCHAR(100) CHARACTE
sasha wrote:
Как мне правильно поменять этот коллейт без пересоздания домена?
Через системные таблицы.
--
Дмитрий Еманов
Hello, sasha!
sasha wrote:
ALTER DOMAIN "ShortVarchar"
TYPE VARCHAR(100) CHARACTER SET WIN1251 COLLATE PXW_CYRL
как нелюбитель доменов, замечу, что написать varchar(100)
ничуть не сложнее чем "ShortVarchar", причем замечу, в двойных
кавычках, и соблюдая регистр букв.
--
Dmitri Kouzmenko, ww
Dmitri Kuzmenko пишет:
как нелюбитель доменов, замечу, что написать varchar(100)
Можно напомнить почему "нелюбитель"? На первый взгляд системность это
хорошо ... Что-то во внутренней реализации?
--
С наилучшими пожеланиями,
Николай Войнов.
Через системные таблицы.
Чё-то я никак не могу найти в какой это таблице. В TYPES нету. Где ещё
эти домены могут лежать?
как нелюбитель доменов, замечу, что написать varchar(100)
ничуть не сложнее чем "ShortVarchar", причем замечу, в двойных
кавычках, и соблюдая регистр букв.
Я когда начинал так делать то честно говоря не знал что с доменами у нас
всё так печально.
On Jan 7, 8:36 pm, sasha <[EMAIL PROTECTED]> wrote:
> > Через системные таблицы.Чё-то я никак не могу найти в какой это таблице. В
> > TYPES нету. Где ещё
> эти домены могут лежать?
RDB$FIELDS
RDB$FIELDS
И правда, кто бы мог подумать... Спасибо!
Hello, Николай!
Николай Войнов wrote:
как нелюбитель доменов, замечу, что написать varchar(100)
Можно напомнить почему "нелюбитель"? На первый взгляд системность это
хорошо ... Что-то во внутренней реализации?
нет, никакого отношения. сугубо практически. Просто домены чаще всего
использу
Hello, Sasha!
sasha wrote:
как нелюбитель доменов, замечу, что написать varchar(100)
ничуть не сложнее чем "ShortVarchar", причем замечу, в двойных
кавычках, и соблюдая регистр букв.
Я когда начинал так делать то честно говоря не знал что с доменами у нас
всё так печально.
Саша, извини мен
Саша, извини меня, но ты еще
1. не знал что с доменами в других субд вообще никак
Не спорю. Однако нам от этого не лучше.
2. сразу начал страдать фигней с именами объектов в двойных кавычках.
Я этим уже года 2 страдаю и буду страдать и ничуть об этом не жалею.
Причём тут это вобще?
нет, никакого отношения. сугубо практически. Просто домены чаще всего
используют именно для такой хрени, вроде
ShortString varchar(100), MiddleString varchar(200), BigString
varchar(1024) и т.п.
Есть у меня и такие. Я наивно предполагал что с помощью ALTED DOMAIN
можно будет сразу у всех пол
Hello, sasha!
sasha wrote:
А это как раз противоречит смыслу доменов, потому что домен это ТИП
ДАННЫХ. И вот как раз как тип данных домены почти не используют.
По моему вы напутали. Все поля с доменом ShortString будут типа
ShortString. А вот классы у них могут быть разные (в терминах ООП),
Скажем так. Я использую домены как типы данных для подобных по смыслу
полей. И я знаю что они для другого немного задумывались, но об этом
можно много рассуждать. Я так понимаю что вы смыс в домене
представляете так:
CustomerId INT
OrderId INT
CustomerId = OrderId -> Exception
да. и это не
Hello, sasha!
sasha wrote:
2. сразу начал страдать фигней с именами объектов в двойных кавычках.
Я этим уже года 2 страдаю и буду страдать и ничуть об этом не жалею.
Причём тут это вобще?
При том. что я могу написать ShortString, shortstring, sHortsTring,
а ты - не можешь :-)
--
Dmitri K
При том. что я могу написать ShortString, shortstring, sHortsTring,
а ты - не можешь :-)
А мне кка раз и надо чтобы не мог ;-)
sasha wrote:
кодировка не меняется
Это я исправил в 2.1. Как-нибудь дойдут руки и до коллейтов.
--
Дмитрий Еманов
Это я исправил в 2.1. Как-нибудь дойдут руки и до коллейтов.
Отлично! А VARCHAR на BLOB TEXT поменять тоже можно будет?
Hello,
Dmitri Kuzmenko said the following on 08.01.2007 13:52:
> Собственно, домены использовать никто не запрещает, и никак
> не ограничивает, поэтому вопрос правильной или неправильной работы с
> доменами сугубо теоретический.
Зато когда, наконец-то, можно будет использовать домены для описан
sasha wrote:
А VARCHAR на BLOB TEXT поменять тоже можно будет?
Гммм... хороший вопрос...
--
Дмитрий Еманов
Гммм... хороший вопрос...
У меня ещё вопрос хороший есть. Существует множество кодировок, которые
можно привести друг к другу. Например:
WIN1251 -> KOI8R
xxx -> NONE
xxx -> UTF8
NONE -> реальная
да и вобще если у меня одни английские буквы, то почти все кодировки
можно менять.
Что-то из
sasha wrote:
У меня ещё вопрос хороший есть. Существует множество кодировок, которые
можно привести друг к другу. Например:
WIN1251 -> KOI8R
xxx -> NONE
xxx -> UTF8
NONE -> реальная
С NONE не так просто, как кажется. Да и в остальных случаях скорее всего
мы разрешать не будем.
да и вобщ
Hello, Igor!
Igor Zakhrebetkov wrote:
FB/IB автоматически создает новый домен для каждого столбца таблицы.
Поэтому IMHO лучше самому логически объединить некоторые столбцы, например
задать для полей FM, IM, OT домен типа CHAR40, чем потом увидеть в своей БД
домены типа RDB$D0001,RDB$D0002 и тп
Hello, Igor!
Igor Zakhrebetkov wrote:
задать для полей FM, IM, OT домен типа CHAR40, чем потом увидеть в своей БД
домены типа RDB$D0001,RDB$D0002 и тп
кстати, если так делать, то лучше уж домены называть C40 или V40, и т.п.
Я серьезно. Потому что пример Владимира Бахвалова - это супер:
DMN_C
Hello,
sasha said the following on 08.01.2007 21:40:
> У меня ещё вопрос хороший есть. Существует множество кодировок, которые
> можно привести друг к другу. Например:
>
> WIN1251 -> KOI8R
Нельзя.
> да и вобще если у меня одни английские буквы, то почти все кодировки
> можно менять.
Да, но н
Да, но нужно перед этим выполнить команду
SET I_HAVE_LATIN_LETTERS_ONLY=SURE
Та ладно. У вы же когда пытаетесь сделать FK на поле с данными, то вам
же не запрещают ключ создавать даже если там неправильные значения есть.
В процессе построения индекса всё выясняется. Так и тут. Есть
неконве
sasha wrote:
Есть неконвертируемые символы - лови Exception.
Это означает:
1) Эксклюзивную блокировку таблицы на время проверки
2) Проверку в режиме грязного чтения
3) Перезагрузку кеша метаданных всех процессов сервера
--
Дмитрий Еманов
Hello, Igor!
Igor Zakhrebetkov wrote:
Какая экономия, просто если домены всё равно есть, лучше хотя бы
с точки зрения эстетики давать им более вразумительные имена
нет здесь никакой "эстетики". с точки зрения РСУБД домен есть только
когда он создан явно. Если РСУБД создает "домены" при объя
Dmitri Kuzmenko wrote:
нет здесь никакой "эстетики".
Ну как же. Ведь можно же на домене задать чек >0, а на использующем
его столбце - <0. Эстетичнааа...
--
Regards. Ded.
Dmitri Kuzmenko пишет:
Igor Zakhrebetkov wrote:
FB/IB автоматически создает новый домен для каждого столбца таблицы.
Поэтому IMHO лучше самому логически объединить некоторые столбцы,
например
задать для полей FM, IM, OT домен типа CHAR40, чем потом увидеть в
своей БД
домены типа RDB$D0001,R
Hello, M!
М.Королев wrote:
Давно не сталкивался, но где-то они все же выскакивали. Вроде бы,
системные имена доменов появлялись в сообщениях об ошибках. Что
приводило к дополнительному колупанию.
ну, если колупать системные таблицы вообще, то оно, конечно... :-)
И если эти FM,IM, OT испол
М.Королев wrote:
А если в 10-20 таблицах и в десятке-другом процедур/триггеров? Я не
конкретно про ФИО. А экономия не в кол-ве нажатий клавиш при наборе
имени, а, например, в уменьшении вероятности ошибки при реструктуризации.
Сдаёццо мне, что вероятность ошибки пропорциональна количеству
А если в 10-20 таблицах и в десятке-другом процедур/триггеров? Я не
конкретно про ФИО. А экономия не в кол-ве нажатий клавиш при наборе
имени, а, например, в уменьшении вероятности ошибки при реструктуризации.
Сдаёццо мне, что вероятность ошибки пропорциональна количеству типов. А
когда в
Hello, Igor!
Igor Zakhrebetkov wrote:
Тут надо бы разобраться, всё-таки их нет, или они есть.
Вот с какого-то ФАКа на ibase.ru:
да бог с ним, с FAQ-ом. Ты можешь назвать свой домен rdb$char40,
но ты должен быть в курсе, что префикс rdb$ зарезервирован системой.
И как там фишка ляжет _в сис
Dmitri Kuzmenko пишет:
М.Королев wrote:
Давно не сталкивался, но где-то они все же выскакивали. Вроде бы,
системные имена доменов появлялись в сообщениях об ошибках. Что
приводило к дополнительному колупанию.
ну, если колупать системные таблицы вообще, то оно, конечно... :-)
Та ни. Без вся
Igor Zakhrebetkov wrote:
Т.е. похоже, что системные домены от пользовательских отличаются только
префиксом "RDB$".
Если я назову свой домен RDB$CHAR40, то чем он будет отличаться
(в том числе и "с точки зрения РСУБД") от автоматически создаваемого
системой какого-нибудь RDB$123?
Sorry, но до
Ded пишет:
М.Королев wrote:
А если в 10-20 таблицах и в десятке-другом процедур/триггеров? Я не
конкретно про ФИО. А экономия не в кол-ве нажатий клавиш при наборе
имени, а, например, в уменьшении вероятности ошибки при реструктуризации.
Сдаёццо мне, что вероятность ошибки пропорциональн
М.Королев wrote:
Эх... Соглашусь конечно, куда девацца...
А потом приведу пример, утрированный в другую сторону :)
И ничего этим не докажу...
Но думаю, золотая середина все же есть и домены придуманы не зря.
На самом деле вопрос - типичный холивар. На мой личный взгляд одни
траблы с возмож
На самом деле вопрос - типичный холивар. На мой личный взгляд одни
траблы с возможными противоречиями по ограничениям между доменами и
столбцами сводят на нет преимущества читабельности. Но это всего лишь мой
взгляд, я не настаиваю на том, чтоб все так же думали. Ну а раз ещё и
использовани
Hello, Ded!
Ded wrote:
На самом деле вопрос - типичный холивар. На мой личный взгляд одни
траблы с возможными противоречиями по ограничениям между доменами и
столбцами сводят на нет преимущества читабельности. Но это всего лишь
absolutely. хотя по теории домены-то как раз нужны в случаях
Dmitri Kuzmenko пишет:
Ded wrote:
На самом деле вопрос - типичный холивар. На мой личный взгляд одни
траблы с возможными противоречиями по ограничениям между доменами и
столбцами сводят на нет преимущества читабельности. Но это всего лишь
absolutely. хотя по теории домены-то как раз нужны
Igor Zakhrebetkov wrote:
То есть проблема с пользовательскими доменами - это отсутствие
уникальности?
В моём понимании - да. Правишь его, не зная где он использован по
делу чи не очень (а даже в средних размеров командах это запросто, да и
склероз-бодун даже если один работаешь) и получа
Hello, Igor!
Igor Zakhrebetkov wrote:
Дык это как бы понятно. И понятно, что ни к чему давать системное имя
домену CHAR40.
Непонятно в чём грабли при попытке использования более человеческих имен
доменов вместо системных RDB$.
что-то я тебя перестал понимать.
--
Dmitri Kouzmenko, www.ib
Hello, M!
М.Королев wrote:
Ничо не понял.
Почему домен должен отражать смысл, да еще в таком узком смысле? :)
Чем плох DNAME в качестве домена для First, Middle и прочих Name'ов?
Чем плох DID в качестве домена для ID'ов (чеки в домен не включаем) ?
От чего спасает наличие разных системных доме
Hello, Igor!
Igor Zakhrebetkov wrote:
Э-э-э, как это LastName и FirstName могут быть разного формату,
но одного домену VCHAR40?
не могут. я и объясняю, что длина строки сама по себе
не является основанием, чтобы все столбцы с такой
длиной строки объявлять от одного домена.
Вот IMHO с каким
Хм, у меня вот например такое есть:
LocalId INTEGER
InstanceId SMALLINT
VersionId SMALLINT
GlobalId BIGINT
и я ними пользуюсь чисто чтобы типы данных не перепутать. Хоть это и не
правильно с точки зрения дейта, зато удобно. Никаких проблем с
пониманием структуры таблиц я здесь не вижу.
Hello, sasha!
sasha wrote:
Хм, у меня вот например такое есть:
LocalId INTEGER
InstanceId SMALLINT
VersionId SMALLINT
GlobalId BIGINT
и я ними пользуюсь чисто чтобы типы данных не перепутать. Хоть это и не
правильно с точки зрения дейта, зато удобно. Никаких проблем с
пониманием структуры
здесь у меня никаких претензий, окромя GlobalId, если я правильно понял
его смысл. А может и не понял.
Это GlobalId = LocalId + InstanceId * 4294967296 + VersionId * ...
Что с ним не так? Тем более в эпоху 64-разрядных процессоров... У меня
все таблицы от малых до больших с этими полями для
Hello, Sasha!
sasha wrote:
Это GlobalId = LocalId + InstanceId * 4294967296 + VersionId * ...
Что с ним не так? Тем более в эпоху 64-разрядных процессоров... У меня
тогда все ok.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Hello, Igor!
Igor Zakhrebetkov wrote:
Дык на ibase.ru для изменения типа или длины поля именно хак приводится:
http://www.ibase.ru/devinfo/changesize.htm
этому документу уже 10 лет.
и написано, что:
"в стандарте (ANSI SQL 92 entry level) нет определени языковых
конструкций для модификац
Какая дисскуссия однако. А я доменами не пользуюсь. Экономить на их
количестве особого смысла не вижу. Писать VCHAR40 вместо VARCHAR(40) - как
то тоже особых плюсов не просматривается. А если придумывать какие-то
универсальные домены типа TNAME - дак это надо их типы в голове держать, а
моск-
Igor Zakhrebetkov wrote:
Sorry, а зачем вообще править домены, рискуя нарваться на грабли, и
не использовать штатную возможность
ALTER TABLE T ALTER A TYPE
?
А какая собсно разница? Alter и есть правка, но предусмотрен именно
и только для тех случаев, когда она безопасна. В том, что
Igor Zakhrebetkov wrote:
Понятно, что имя у домена должно быть не RDB$CHAR40, а просто CHAR40.
Уууу... Процесс создания Всемирной Конституции "по-мне" пошёл...
/* кстати, здесь IBExpert культурно покажет, что CHAR40=CHAR(40) */
Да-да-да. Сервер должен стать таким, как Эксперт, а ещё
Igor Zakhrebetkov wrote:
дык тогда откуда грабли у домена RDB$1665 выше по треду ?
:)
Это меня тоже сильно интересует и без смайла. Он не один такой, к
сожалению. Первое что приходит в голову - создание полей на фоне
какого-то повреждённого системного индекса. Или застрявшего при падени
Hello, Igor!
Igor Zakhrebetkov wrote:
потому что руки не доходят в таком количестве документов все править.
Sorry, я же не упрекаю (а просто ехидничаю :))
да я в общем, тоже, не рыдаю от горя :-)
А IB 6 существует уже считай 7 лет.
Доки от 17.11.99 - так что юбилей уже пропустили :(
Dmitri Kuzmenko пишет:
М.Королев wrote:
Ничо не понял.
Почему домен должен отражать смысл, да еще в таком узком смысле? :)
Чем плох DNAME в качестве домена для First, Middle и прочих Name'ов?
Чем плох DID в качестве домена для ID'ов (чеки в домен не включаем) ?
От чего спасает наличие разных си
Hello, M!
вот, только сейчас руки дошли ответить.
М.Королев wrote:
Так вот. Я бы принял (с натяжкой) это в качестве аргумента, если бы
собирался в рантайме анализировать имя домена и выполнять какую-то
обработку данных, зависящую от этого имени. Ну например, автоматически
преобразовывать вс
Привет, Dmitri!
Вы пишешь 13 января 2007:
[Sorry, skipped]
DK> значит так. Давай оговоримся, что лично я против
DK> create domain DID INT NOT NULL.
DK> Который никакой смысловой нагрузки кроме INT NOT NULL не несет.
DK> (или кроме varchar(40) и т.п.)
SELECT COUNT(*) FROM RDB$RELATION_FIELDS
==
"Alex Cherednichenko" ...
> SELECT COUNT(*) FROM RDB$RELATION_FIELDS
> ==
>12 234
>
> А это всё (вкупе с правами), влияет на время Prepare.
> Так что, смысл в общем-то, есть, пусть и незначительный.
Мгмгмм... мерял ?
--
Хорсун Влад
Привет, Vlad!
Вы пишешь 13 января 2007:
>> А это всё (вкупе с правами), влияет на время Prepare.
>> Так что, смысл в общем-то, есть, пусть и незначительный.
VH> Мгмгмм... мерял ?
У нас и мелкоскоп имеется.
А то быват ещё оптицкий обман здрения... (С)
--
With best regards, Alex Cheredni
sasha wrote:
Также имеется вопрос: у меня есть домен
... VARCHAR(100) CHARACTER SET WIN1251 COLLATE WIN1251
мне надо получить
... VARCHAR(100) CHARACTER SET WIN1251 COLLATE PXW_CYRL
Что-то не нашел, ответил кто-то или нет.
А что мешает создать новый домен с нужным collate,
и переключить все
Что-то не нашел, ответил кто-то или нет.
А что мешает создать новый домен с нужным collate,
и переключить все поля на него?
IBExpert что-то похожее мутит.
А я так не пробовал. У меня полей много. На то я домен и делал чтобы все
сразу их колбасить.
62 matches
Mail list logo
