-
-
> ANB (26.11.08 17:16) [159]
> У оракла - CLOB.
У всех такое счастье есть. Так шо не показатель.
-
> SELECT > ..., > ARRAY(somefield FROM sometable) > FROM
select collect(somefield) as strarr from somewhere
завести словаре strarr и преобразовать в строку strarr - задача 3-х часов, которая выполняется один раз в жизни
-
> ANB (26.11.08 14:32) [151]
> А пока никак. Тоже ждемс.
а с pipeline-функциями не разбирался? говорят, в рязани этой фичей проблема решается. Сам не лез, не надо было просто.
-
Кстати, может кто-нибудь пояснить фишку с наследованием таблиц? где это используется?
-
> а с pipeline-функциями не разбирался? говорят, в рязани > этой фичей проблема решается. Сам не лез, не надо было просто. >
Та и обычной функцией решается. А пипелайновые функции - штука полезная, но редко. И на наших объемах часто неприменимая.
-
> Кстати, может кто-нибудь пояснить фишку с наследованием > таблиц? > где это используется?
4 года назад мы с Alkid-ом это вручную на MSSQL городили. Задача такая была. Самый простой пример - ORM с наследованием.
-
> Ega23 © (27.11.08 10:50) [166] > Самый простой пример - ORM с наследованием.
А нужда какая заставила? В чем это на практике выгодно/удобно (дорого/богато)?
-
> А нужда какая заставила? В чем это на практике выгодно/удобно > (дорого/богато)?
Ну вот представь, есть у тебя некий "конструктор", типа как Delphi. Накидал компонентов, увязал их между собой - и готов клиент в такой или в такой конфигурации. Заказчик захотел "дополнительной эксклюзивной фичи" - новый "кирпичик" делаешь и специально для него включаешь его в дистрибутив. А все эти объекты - в БД хранятся. Каждая таблица - суть класс, каждая запись - суть экземпляр класса.
-
> Ega23 © (27.11.08 11:29) [168]
С ораклом такие конструкторы тоже прекрасно работают. А как доп.фича - всю логику тоже можно засунуть на сервер. В клиенте будет только визуалка.
-
> Поросенок Винни-Пух (26.11.2008 15:57:34) [154]
А еще точнее, и желательно такой же ответ для MS SQL
-
А почему FireBird так медленно продвигается/развивается ? Вроде другие Free СУБД намного активней развиваются… И сколько как думаете “проживет” FireBird ?
-
> nicak (05.12.2008 13:39:51) [171]
Всегда найдутся люди, которым скучно.
-
> А почему FireBird так медленно продвигается/развивается?
Всё нижесказанное - моё сугубо личное мнение.
1. В СССР почему-то Паскаль был гораздо популярнее того-же C/C++. По крайней мере, в институте, где батя работает, C начал "продвигаться" не так давно. Все на Паскале писали. Опять же, когда в МИФИ учился в начале 90-х, основным языком опять же был Паскаль. Почему - не знаю.
2. С широким распространением Windows в стране, где многие пол-жизни писали на Паскале + не сильно соблюдались всякие лицензионные политики (а по сути - вообще не соблюдались), популярность Delphi как основного средства разработки была предрешена.
3. Во всех старых книжках по тому же Delphi (я самую древнюю для D3 видел-читал, хотя есть и Лишнер, там для D2, но в ней про БД ничего нет) основные примеры разбирались на том, что доступно. Можно замечательную книгу написать "Delphi + Oracle" или "Delphi + MSSQL". Только популярность её будет, ну не знаю. Сомнительная, что-ли. А из доступного был Paradox да IB, который до определённого момента усиленно Борландом продвигался.
4. Вследствие этого в тех же Дельфях появились достаточно продвинутые компоненты доступа для работы с IB-like СУБД. Соответственно, достаточно большое число долгосрочных проектов начиналось аккурат под IB и, впоследствии, FB.
5. Собственно, вот и ответ. У нас в стране есть N-ое количество продуктов под IB/FB, которые требуют поддержки/доработки. И лично у меня складывается впечатление, что такая ситуация только на территории ex-USSR. Где-нибудь во Франции про FB мало кто знает. Также в стране есть масса специалистов, которые долгое время писали под IB/FB, знают массу тонких возможностей, подводных камней, досконально знают DAC, имеют готовые фреймворки или заготовки. И таким людям - да, гораздо проще начать какой-нибудь продукт на FB, т.к. можно пропустить момент Getting Started.
6. Ну и самое главное. Время программистов-одиночек, ИМХО, прошло. Предприятию гораздо проще купить "1С-склад" за $2000 (цена - условная) и нанять приходящего программиста, который будет это дело иногда конфигурить, чем нанимать в штат программера для написания этого дела "с нуля". А где большие софтверные решения - там и СУБД серьёзные.
-
-
|