а что за тип такой - GUID ?
мне просто не надо было, а будет интересно - можно и создать.
А еще sequence можно иметь, и хоть для всех таблиц в базе можно один sequence использовать - гарантировано совпадения не будет.
Просто если стоит задача - надо решать, и делиться созданным.
Я вот думаю тип данных IP создать.
Вроде, и не нужно, но интересно :)

DB2
Странно, что DB2 его до сих пор "найтивно" не поддерживает.
Тот же oracle кросплатформенный, но GUID поддерживает.

Вообще, удобное "средство" для кросплатформенной, кросбазной, кроссистемной идентификации и создания всяческих собственных "механизмов репликации".
Могу предположить, никому из клиентов надо небыло.
Вона, SAP'у как что понадобилось, так столько фич реализовали!
А с репликацией вроде проблем нет и без GUID
А в Q Replication используется MsgID от MQ , хоть ему и не надо быть world-wide unique, свою задачу выполняет, по идентификации сообщений.
А если никому не надо - то кто будет делать???

да сделать можно - просто он желает, чтобы IBM сделал.
Я думаю, за некоторое кол-во денег IBM сделает.
Или gardenman, если его заинтересовать :)

чтобы пользоваться чем-то - нужна задача.
Ну если нету задачи по использованию GUID....
Была бы - было бы сделано.
Кстати, замечание по поводу "внешних" процедур - а если она выполняется в адресном пространстве db2 - тогда она уже не внешняя ?
Зачем сделал оракл - я не знаю, возможно, по просьбе кого-нибудь из клиентов.
Но еще раз - если никто из клиентов не просил IBM - то что, тупо копировать все то, что делали конкуренты ? Тупиковый путь.
Это не наез да GUID, а просто непонятна логика - вот у MSSQL есть, даже oracle сделал... А IBM нет.
А про 21 век - не смешно. Пока не видно, чтобы появилось что-нибудь более удобное, чем создание скриптов. Во всяком случае мои знакомые ораклоиды такого же мнения.
Кстати, а какая беда с linux? Там же все API доступно, сырцы есть, то есть реализовать все можно, можно даже силами адекватного студента, вряд ли там код будет на уровне сложного research.

а при чем здесь - держит в голове???
Это у вас путаница какая-то.
Использование скриптов и держание в голове никакими веревками вместе не связано.
И огромное кол-ва DBA обслуживающих всякие разние системы как раз скрипты и пользуют
Это и возможность подумать, пока скрипт составляешь.
Это и воспроизводимость результата, а не "О черт, куда же я ткнул! Что же оно сделало?!"
И отчет о проделаном, и как дока о проделаном другим участникам, и продолжить по вкусу.

я не видел ни одной задачи, которую можно было бы решить лучше и удобнее в GUI чем из скрипта.
Зато есть перцы, которые натыкают мышой в чем-нибудь типа MQ Explorer, а потом просят PMR открыть - видите ли, MQ не так работает. А когда все по шагам (по скриптам) то оказывается все так, и все просто и прозрачно. Потом просят скрипты дать (даже кто на windows)

не вижу никакой связи GUI - память которая человеческая.
Никто не заставляет писать скрипты, удерживая всю структуру базы в голове.
Да на любом более-менее серйозном проекте это и невозможно.
Помогает ввести параметры - согласен, возможно, кому-то это и нужно. И важно.
результат в наглядном виде? субъективно! Не согласен.

Да, кстати, я не с рождения на db2, были и другие базы, и покупные GUI, ведущие на рынке в те времена.

DB2
Почему вы так уверенно говорите за IBM? Может эта задача у них то же на повестке дня. Просто, возможно, есть и более первостепенные задачи чем эта. Например добиться того же user friendly.
Потому что довольно хорошо известно, чем занимается IBM в db2. Почитайте, что делается в бете.
А user friendly - это очень субъективно.
Для меня dbaccess информикса (ncurses based) был очень неудобен, когда канал доступа к базе оказался забит.

DB2 ggvа при чем здесь - держит в голове??? Это у вас путаница какая-то. Использование скриптов и держание в голове никакими веревками вместе не связано. Это и возможность подумать, пока скрипт составляешь...То ли мы о разных вещах говорим, то ли, следуя вашей логике, IBM свой "жаба-менеджер" исключительно для "лохов" создавал, а не для удобства пользования и администрирования собственного продукта.

Еще раз - использоване скриптов не требует удержания структуры базы в голове, и это никакого отношения не имеет, к чему IBM создавал db2cc
А для удобства администрирования IBM много чего делает - смотрите, что в бете добавляют.

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

Я боюсь только, что мы все равно говорим о разных вещах.
Вы пытаетесь противопоставить GUI и скриптописание. Я же вовсе не пытаюсь их противопоставлять. Хорошему продукту - хороший GUI - это подспорье и удобство.
Я так же считаю, что хороший GUI может сильно упростить и ускорить многие рутинные действия, связанные с дизайном и проектированием. К тому же очень сильно помочь в структурном понимании области и задачи, как самим проектировщиком так и остальными разработчиками.


Передергивание - я не пытаюсь противопоставить.
Просто есть есть такие требования, и меня так учили, требовали, и я так учил и требовал, что выполнение задачи принимается только после появления файла в систему управления версиями. В виде скрипта.
Только не предлагайте записывать последовательность кликаний мышой по экрану :)
Это просто разный подход и разный уровень ответсвенности.
При таком подходе наличие GUI никак не отрицается. Используй на здоровье. Но результаты использования будь любезен, оформи как положено, и выложи, куда указано. И неси за это ответсвенность.
Пару лет - и сразу начинаешь скрипты писать, вместо кликаний :)

А вот по поводу GUI может упростить проектирование и дизайн - нет, не может, заблуждение. GUI может помочь в визуализации, но есть и другие методы визуализации структур, в разных нотациях. Если в голове в плане проектирования все в порядке, и проектировщик знаком с нотациями, и может результаты своего проетирования офрмить и опять же в систему контроля версий положить.... То это не то, чтобы отрицает GUI, нет, это просто не требует GUI. А диаграмы и прочие вещи можно разными средствами строить , в том числе и без GUI. А можно и разными программами GUI.

DB2Жаль, не знаю, как картинки сюда цапануть, а то я бы вам показал, не голословно и не на пальцах, что я имею в виду.
Нет, не надо, увольте :)
Вы уж лучше писменным языком изложите свои мысли :)

на форуме спор - это что, а когда "родной" свой разработчик говорит - ну нафига я должен эту вещь в виде скрипта, да еще в CVS, тут же все тривиально, я вот мышой за пару секунд сделаю...
Вот где проблема :)
Приходится мягко, но настойчиво - делай, дорогой, делай, но незабудь экспортировать сделанное в скрипт (если тулз позволяет, db2cc - да) и выложить в CVS, иначе будем считать - ты ничего не делал :)
Ну каналы сейчас редко плохие бывают, хотя хоть и редко... Но не дай бог :)

ключевое слово - я сам себе дизайнер, и никто меняя не контролирует.
О многом говорит.
А вот теперь представте, что все любые изменения придумываются-тестируются одним, выкладываются в CVS, чекаются облеченными полномочиями людьми, и накатываются совсем другими людьми.
И грубо говоря оценка деятельности идет по результатам в CVS.
А то, что GUI должен позволять выгружать накликанное в скрипт - святая правда. Если не позволяет - убивать такой GUI.

По поводу каналов плохих - никогда в бизнесе у меня небыло простого способа попасть к серверу баз данных, даже если он был в том же городе. А часто на другом континенте, и при любой толщине канала в инете случаются периодически проблемы, и если они случайно наложатся на проблемы компании... Я посморю, как оно у вас в ГУЯх пойдет

Viktor - не убедительно. Про Backup и Restore. Потому что в бытность свою, я приходил в оффис, и заявлял базовикам - все, база сдохла, время пошло. И докладывал результаты financial director, посикоку он у нас самый главный был. Поверьте, проблем небыло, что не помнили - быстро знали где посмотреть, хотя, все было готово, все скрипты с параметрами. Ну и условия тренинга меняли по-всякому.
Про Alter тоже не убедительно, когда вся схема перед глазами, структура, а она обязана быть перед глазами постоянно, то проблем не возникает.
Ну не вижу я никаких преимуществ GUI кроме недостатков, коих за годы насмотрелся множество.

Хех, а как вам помимо CVS еще и бумажный носитель - толстенный журнал - со всеми листингами???
Не видели? Нет? А ведь бывает! Требуется!
И с пояснениями, на аглицком, а в команде более десятка разных стран, и многие из них в своих странах, и видно их только по файлам в CVS, а все одно - распечатай и приложи.
А вы мне про GUI будете убеждать :)
Не убедительно - для жизни это ну никак не самое важное. Главное - правильно процессы формализовать. И хоть многие у себя на компах GUI использовали для работы с базой, група админов - никогда.

И повторю для "DB2" - наличие GUI НЕ ОБЯЗАТЕЛЬНО для визуального представления структуры базы. Более того, такое визуальное представление можно получить и программно, но без GUI. Вы не путайте визуальное представление, и наличие GUI. Это только для вас одно и то же.

Вот, совсем недавно появился MQ Explorer на linux, раньше токо на винде был.
Блин, ей-богу, лучше бы и на винде снесли нафиг.
Сколько раз натыкался на - не работает! - из-за того, что monkey накликав мышой не мог повторить ни словами, ни скриптами, чего он наделал. Приходилось с пояснениями, по слогам, по шагам, показывать и пояснять, как чё надо делать, чтоб все работало, но в runmqsc скриптами. И ничего - понимали.
Поэто если завтра, к примеру, у db2 исчезнет db2cc - я не сразу и замечу, только по сообщениям в этом форуме :)
ну а остальные тулзы я и не пробовал.

Блиииинннн, ну при чем здесь GUI и визуальное представление структуры!!!
Вот уж где дремучесть!!!
Еще раз, внимательно читайте - визуализация структуры никак не привязана к GUI, можно построить структуры базы кучей средств, и есть средства командного описания объектов и их взаимосвязей, аттрибутов, которые строят прекрасные картинки и диаграммы со структурой!
Да, удобно смотреть на визуальную структуру, а не на набор скриптов!
Но при чем здесь GUI???
Или мы слаще морковки ничего не видали?
И если я строю структуры без GUI, но в UML и ER - то я что-то делаю неправильно???
И при чем здесь ваш пример???
И опять же - рутинная операция это сильно субъективно. За неправильную рутинную операцию могут и взашей погнать :)
Да ладно, надо лет чераз -надцать вернутся к вопросу :)
Я ведь тоже в конце 80х мечтал о GUI везде, юзая электроника БК 0010-01, если не перевираю модель, в середине 90х использовал везде, пока не наняли на работу в компанию другого плана, и через примерно шесть месяцев у меня все привычки и устремления поменялись :)
А формализма и консерватизма сильно добавилось :)
Поэтому и утверждаю - GUI не есть обязательная составляющая. Проект любой сложности можно построить и без GUI. И зачастую так будет лучше и эффективнее.

Alexey - да они навреное представить не могут :)
был у меня проект по реинжинерингу, и был PowerBuilder, или Designer, не скажу, в который залили структуры базы, и получили нечто, что и под мелкоскопом не разглядишь :)
ну выкрутились - огромную стену офиса выделили под наш "Designer2000" как мы его называли :)
Вся структура струдом поместилась на стене, но было чертовски удобно!
Кстати, все констраинты там разместили, триггеры, а вот движение данных не поместилось :)
У меня скепсис приобретенный, а не врожденный.
Поетому, если когда-нибудь и придется опять проект возглавить, первым требованием будет большая свободная стена :)
Ну глухая дверь само собой.
А молодежи, которой выделен модуль для разработки, хватит и GUI, лишь бы скрипты генерил для CVS (subversion не было еще тогда)

по этому поводу вспоминается анекдот
Самое страшное слово ядерной физики - oops.....

я к тому, что oops получить более вероятно в GUI, чем набивая текст в редакторе.
Это еще одна из причин, почему я не принимаю участия в телефонных разговорах по типа "описанию задачи" или "описанию проблемы" - завсегда это только поток сознания. Если добиться общения по email, то выше вероятность нормального описания, хоть бывают и тяжелые случаи :) когда "клиент" ну никак не может сформулировать :)