PostgreSQL, MySQL, IB, FB

← →
GlFox © (2008-11-26 18:12) [160]

> [153] ANB (26.11.08 15:34)
> Мне надо что то вроде :
>
> select
> gr_id
> ,sum(X)
> ,gr_concat(Y)
> from
> T1
> group by
> gr_id
>
> Склеить строку на pl/sql я и сам могу.

MySQL: GROUP_CONCAT() http://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html#function_group-concat
Firebird: LIST() http://firebirdsql.org/rlsnotesh/rlsnotes210.html#rnfb210-list

← →
pasha_golub © (2008-11-26 18:51) [161]

> ANB (26.11.08 17:16) [159]

> У оракла - CLOB.

У всех такое счастье есть. Так шо не показатель.

← →
Petr V. Abramov © (2008-11-27 00:41) [162]

> SELECT
> ...,
> ARRAY(somefield FROM sometable)
> FROM

select collect(somefield) as strarr
from somewhere

завести словаре strarr и преобразовать в строку strarr - задача 3-х часов, которая выполняется один раз в жизни

← →
Petr V. Abramov © (2008-11-27 01:02) [163]

> ANB (26.11.08 14:32) [151]

> А пока никак. Тоже ждемс.

а с pipeline-функциями не разбирался? говорят, в рязани этой фичей проблема решается. Сам не лез, не надо было просто.

← →
Cobalt © (2008-11-27 10:31) [164]

Кстати, может кто-нибудь пояснить фишку с наследованием таблиц?
где это используется?

← →
ANB (2008-11-27 10:39) [165]

> а с pipeline-функциями не разбирался? говорят, в рязани
> этой фичей проблема решается. Сам не лез, не надо было просто.
>

Та и обычной функцией решается. А пипелайновые функции - штука полезная, но редко. И на наших объемах часто неприменимая.

← →
Ega23 © (2008-11-27 10:50) [166]

> Кстати, может кто-нибудь пояснить фишку с наследованием
> таблиц?
> где это используется?

4 года назад мы с Alkid-ом это вручную на MSSQL городили. Задача такая была.
Самый простой пример - ORM с наследованием.

← →
Cobalt © (2008-11-27 11:12) [167]

> Ega23 © (27.11.08 10:50) [166]
> Самый простой пример - ORM с наследованием.

А нужда какая заставила? В чем это на практике выгодно/удобно (дорого/богато)?

← →
Ega23 © (2008-11-27 11:29) [168]

> А нужда какая заставила? В чем это на практике выгодно/удобно
> (дорого/богато)?

Ну вот представь, есть у тебя некий "конструктор", типа как Delphi. Накидал компонентов, увязал их между собой - и готов клиент в такой или в такой конфигурации. Заказчик захотел "дополнительной эксклюзивной фичи" - новый "кирпичик" делаешь и специально для него включаешь его в дистрибутив.
А все эти объекты - в БД хранятся. Каждая таблица - суть класс, каждая запись - суть экземпляр класса.

← →
ANB (2008-11-27 12:31) [169]

> Ega23 © (27.11.08 11:29) [168]

С ораклом такие конструкторы тоже прекрасно работают. А как доп.фича - всю логику тоже можно засунуть на сервер. В клиенте будет только визуалка.

← →
Anatoly Podgoretsky © (2008-11-27 15:17) [170]

> Поросенок Винни-Пух (26.11.2008 15:57:34) [154]

А еще точнее, и желательно такой же ответ для MS SQL

← →
nicak (2008-12-05 13:39) [171]

А почему 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 (цена - условная) и нанять приходящего программиста, который будет это дело иногда конфигурить, чем нанимать в штат программера для написания этого дела "с нуля". А где большие софтверные решения - там и СУБД серьёзные.

← →
Городской Шаман (2008-12-05 14:50) [174]

> Василий Жогарев © (26.09.08 13:40) [34]
>
>
> > Gombas
>
> Сорри... Gambas...

А на wxWidgets не встаёт?

http://www.wxwidgets.org/about/screensh.htm

← →
Городской Шаман (2008-12-05 14:57) [175]

Вот к нему визуальный редактор форм
http://wxformbuilder.org/?page_id=38

PostgreSQL, MySQL, IB, FB Найти похожие ветки