interbase - подходит под мощную промышленную систему?

[vgrigor]

interbase - подходит под мощную промышленную систему?

т.е. мощность, возможности,
и.т.д.

по сравнению с MS SQL server.

легко ли делать сложные функции:

гибкая репликация, из программ возможна ?

[Dimitry Sibiryakov]

interbase - подходит под мощную промышленную систему?

Вполне. Но чем мощнее система тем прямее должны быть руки ее создателей.

по сравнению с MS SQL server.

Совершенно другая идеология.

гибкая репликация, из программ возможна ?

В мире софта вообще возможно все. Но ответ зависит от твоего понимания "гибкой репликации" "из программ". Существует довольно много репликаторов как халявных так и коммерческих.

[vgrigor]

Вот в SQL server есть программируемые обдьекты репликации.

т.е. я встраиваю их в свою программу- и они будут работать из моей программы а не левых и отдельных поставщиков.

Это явное преимущество т.к. я все сделаю как мне надо.

Эта технология гибкая т.к. управляется запросами,
частичная репликация, по вырезам, и.т.д.

т.е. все оптимально и без изучения и привлечения других программ.
и из любого языка поддерживающего СОМ.


А в interbase?
______________

про MS SQL можно сказать просто - поддерживает все черты мощных систем, как - надежность, масштабируемость,
и не нужна особая прямизна когда все отработано и описано как.

т.е. это практикуется, проверено,
и рекоменудуемо многими.

А в interbase?

[Merlin]

про MS SQL можно сказать просто - поддерживает все черты мощных систем, как - надежность, масштабируемость,
и не нужна особая прямизна когда все отработано и описано как.

т.е. это практикуется, проверено,
и рекоменудуемо многими.

Ага. Вот тока я заманался пальцы загибать насчёт случаев вложения нескольких миллионов во внедрение Аксапты и последующего выбрасывания её на помойку из-за блокировок в базе M$ SQL.

[vgrigor]

покажите линк на описание данной проблемы?

чтобы проверить что сведения не со слуха,
и не со сплетен.

микрософт серьезная компания, чтобы на такие мелочи напарываться.

[kdv]

Вот в SQL server есть программируемые обдьекты репликации.

типа пальцЫ? фигня это все. Репликация по умолчанию есть только в Lotus Notes, в РСУБД ее надо писать самостоятельно. Все что входит в комплект РСУБД в отношении репликации - обычно муйня.

[andreik]

interbase - ïîäõîäèò ïîä ìîùíóþ ïðîìûøëåííóþ ñèñòåìó?

ñàì ñåðâåð âñåãî ëèøü ÷àñòü ïðèëîæåíèÿ. è îòâåò íà ýòîò âîïðîñ ìîæíî äàòü òîëüêî â êàæäîì êîíêðåòíîì ñëó÷àå. ò.å. êëèåíòñêóþ ÷àñòü ìîæíî íàïèñàòü òàê, ÷òî óæå 5-6 ïîäêëþ÷åíèé "ïîëîæàò" äâóõïðîöåññîðíûé ñåðâàê ñ 4 ãèãàìè ïàìÿòè è íàîáîðîò, ìîæíî íàïèñàòü òàê, òî 40-50 îäíîâðåìåííûõ ïîäêëþ÷åíèé áóäóò îáñëóæèâàòüñÿ îäíîïðîöåññîðíûì àòëîíîì ñ 2 Ãá ïàìÿòè.

ïî ñðàâíåíèþ ñ MS SQL server.

ñì. âûøå

ëåãêî ëè äåëàòü ñëîæíûå ôóíêöèè:
ãèáêàÿ ðåïëèêàöèÿ, èç ïðîãðàìì âîçìîæíà ?

â ðåëÿöèîííîé áàçå äàííûõ ðåïëèêàöèÿ òðåáóåò:
1) àäàïòàöèè ñòðóêòóðû áàçû ïîä ðåïëèêàöèþ
2) èíñòðóìåíòà (ðåïëèêàòîðà)

ïåðâîå, çàâèñèò îò âàñ. âòîðîå -- ïîèùèòå â èíåòå. íà ñåãîäíÿøíèé äåíü õâàòàåò.

ñêàæó ïî ñâîåìó îïûòó, ìû íàïèñàëè ïëàòôîðìó, ïîñòðåëÿöèîííóþ îáúåêòíî-îðèåíòèðîâàííóþ ñðåäó, êîòîðàÿ â êà÷åñòâå ñåðâåðà èñïîëüçóåò Interbase/Yaffil/Firebird. È íà íåé ñîçäàåì ïðèëîæåíèÿ. Òàê âîò, èíòåðáåéç âïîëíå ñïðàâëÿåòñÿ ñ òàêèìè çàäà÷àìè, êàê àâòîìàòèçàöèÿ ìÿñîêîìáèíàòà, íàïðèìåð. Ðàçìåð áàçû 7-8 Ãá, ñåðâåð -- 2-õ ïðîöåññîðíûé ïåíòèóì, 3 Ãá ïàìÿòè. Èìååòñÿ äâå äîïîëíèòåëüíûõ áàçû: îäíà ñîáèðàåò èíôîðìàöèþ ñ ïðîèçâîäñòâåííûõ ëèíèé, âòîðàÿ -- îáñëóæèâàåò îòäåë ïîñòàâîê. Îòäåëüíûå áàçû ïîíàäîáèëèñü äëÿ ïðîèçâîäèòåëüíîñòè. Ò.å. ÷òîáû ïðîèçâîäñòâåííàÿ ëèíèÿ íå ïðîñòàèâàëà, à êëèåíò íå "âèñåë" íà òåëåôîíå, êîãäà áàçà çàãðóæåíà ïîñòðîåíèåì àíàëèòè÷åñêîãî îò÷åòà. Ìåæäó áàçàìè íàñòðîåíà ðåïëèêàöèÿ. Ò.å. ôàêòè÷åñêè, âðó÷íóþ, ñîáðàí êëàñòåð. Áîëåå ïîäðîáíî òóò: http://www.gsbelarus.com

[vgrigor]

Я вот не понимаю почему типичная задача - репликации,
не может быть сделана с помощь настраеваемого средства?

все что делают руками и тулами, можно и удобнее сделать спомощью
програмного инструмента,
какие конкретные проблемы в этом случае?
_________________________

Нассчте масщтабируемости - с помощью каких методов можно
положить базу данных "4 соединениями"-
с помощью потребления всех данных на клиент ?
т.е. без организации слоя бизнес логики?

или какие типичные ошибки в данном случае ?

как это лучшим образом решается?

[kdv]

Я вот не понимаю почему типичная задача - репликации,
не может быть сделана с помощь настраеваемого средства?

все очень просто. Допустим, у тебя складское приложение. И оно не имеет понятия (в структурах таблиц) про то, что могут быть 2 склада. Когда появляется второй склад, ты хочешь репликацию, и ... ?
потом, односторонняя репликация - это не репликация, это тиражирование.

Почитай, к примеру, вот это - http://replication.chat.ru/
потом возьми описание на любой штатный репликатор, и сравни, чего он может, а чего нет. Для IB/FB готовые средства репликации есть, это не вопрос.

Насчет масштабируемости - с помощью каких методов можно
положить базу данных "4 соединениями"-
с помощью потребления всех данных на клиент ?
т.е. без организации слоя бизнес логики?

1. понасоздавать индексов на все столбцы
2. выбирать ВСЕ данные на клиента, сортируя их на сервере и каждый раз перетаскивая заново
3. создать тучу триггеров, check constraint и т.п., которые будут выполнять запросы (особенно с агрегатами), вместо нормального написания sql (допустим, join), вызываемого из клиентских приложений
и т.д., и т.п.

или какие типичные ошибки в данном случае ?
как это лучшим образом решается?

чтением статей, тонн документации и собственным опытом.

[vgrigor]

чтением статей, тонн документации и собственным опытом.

вот тут "не очень" круто,
неужели нет краткого списка наибольших и типичных неприятностей
органзации БД ?
- отправка к тоннам БД - бюрократичская отписка:
повторить пути тех кто делал это нептимизированно,
и боятся поделиться своим опытом.

не хочется поделиться?
(весьма в краткой, но адекватной форме)
это же форум, я и спрашиваю.

одна проблема- одно предложение,
т.к. базовые технологии всем тут известны.
я не про общее образование спрашиваю.

[Karp]

вот тут "не очень" круто,
неужели нет краткого списка наибольших и типичных неприятностей
органзации БД ?
не хочется поделиться?
(весьма в краткой, но адекватной форме)
это же форум, я и спрашиваю.

Мил человек, на этом сайте (www.ibase.ru) есть куча статей в разделе документация, можно было хотя бы на оглавление взглянуть, и о чудо увидеть статью # что НЕ надо (или нельзя) делать при работе с Interbase , а не возмущаться, читать надо, и чес больше, тем лучше, что тебе и сказали тут

[kdv]

неужели нет краткого списка наибольших и типичных неприятностей органзации БД ?

что-что??? ошибки проектировщика - это ошибки проектировщика, не более того. КАК проектировать БД - есть очень много книжек. Как НЕ надо делать - это приходит с опытом, при проектировании конкретной прикладной системы. 3 разных человека запроектируют одну и ту же БД на 50% по разному, если это не "телефонный справочник", конечно.
Разумеется, есть общие схемы, но они опять же, изложены (и доступны в интернете) вообще, и IB/FB тут ни при чем.

- отправка к тоннам БД - бюрократичская отписка:
повторить пути тех кто делал это нептимизированно,
и боятся поделиться своим опытом.

эээээ.... зеленый? Те кто хотел, написал статьи. Или ответит (или уже отвечал) на подобные вопросы на форуме. Остальные РАБОТАЮТ, и за свои решения ПОЛУЧАЮТ ДЕНЬГИ. Твои претензии выглядят как желание получить готовое на халяву. Нет?

одна проблема- одно предложение,
т.к. базовые технологии всем тут известны.
я не про общее образование спрашиваю.

а тут никто общего образования и не предлагает. Хотя, если ты задаешь такие вопросы, то тебе именно общего образования (хотя бы по репликации) и не хватает.

[Vas]

3. создать тучу триггеров, check constraint и т.п., которые будут выполнять запросы (особенно с агрегатами), вместо нормального написания sql (допустим, join), вызываемого из клиентских приложений

Кстати насчет нормального написания join. Оптимизатор в интербейсе мягко говоря очень странный. И зачастую "нормально написанный join" будет работать непотребно медленно, в результате чего потребуется ручная оптимизация, и "нормально написанный join" превратится в "ненормально написанный join" типа
from a join b on b.ref_a+0=a.id
where b.condition+0 in (1,3,7)
И прочими приколами типа UPDATE A SET X=1, Y=X
Интересно кстати когда это планируется исправить ?
А вообще у нас база на интербейсе (7-я версия), и мы вроде довольны пока что всем, за исключением таких неприятных случаев.
И насчет блокировок в MSSQL с последней версии с ним можно работать в версионном режиме.

[vgrigor]

kdv,

если я хорошо разбираюсь в определенной технолгии,

я быстро могу указать какие 2-4 метода применяются для организации масштабирования web-решений.

А если отсылаю к статьям то знание неформализировано.

И можно обвинять спросившего в желании халявы, а не отвечать.
Удобный прием. кто пользуется заведо умный не отвечая по теме.

Я сертифицированный микрософт по распределенные приложения на С++, так что я не халявщик,
просто в области баз данных не "все прочесал", чтобы вынести те 5-6 решения которые нужны,

про тоны- я тут не имею в виду неоптимизированные SQL запросы,
хотя тип их можно указать если есть особо зловродный.

________________________--

примеры:
iT>Следите, чтобы никакие запросы не зависели линейно (прямо или косвенно, через объем данных) от времени работы системы.

т.е. периодическая агрегация в "общие данные" (не так детализированные)
и вынос в архив ?

3-уровневость -
iT>Основное средство? Хм.. Нет, основное средство — это все-таки правильная структура БД.

[vgrigor]

Про первичный ключ- это действительно вопрос для разряда
"а что для начинающих".

Но тут задача другая:
подготовить методику следуя которой другая группа разработчиков,
получит масштабируемую и производительную базу,
(в общем - даже распрееленную)

т.е. не подходящий совет.

они конечно знают про первичный ключ как и я,
но проблема в том что вопрос не в элементарных деталях,
а в хорошей конструкции, и умении ее определять.

теорию нормализации надо считать известной.
о том что не всегда нужна на малых базах -тоже.

[vgrigor]

хотя мне нужны советы,
хотя и общего характера,
но выражающие конкретные правила
в данной области,

почему нельзя это формулировать?

тут есть некоторая хитрость:
да конечно все требует анализа и проработки по конкретному применению,
но правила из которых комбинируются или выбираются лучшие решения - это они же,
просто применять их надо осознанно конечно,

но сами правила эти можно перечислить,
если формулировал для себя?

в других областях я могу составить такое,
и делаю тоже,
но вот по масштабируемости баз- я просто не занимался так подробно крупными системами.

если это могу сделать я сам в других областях,
почему мне не могут присоветовать это же в базах по масштабируемости ?

может хочется чтобы и другие "по-страдали тоже" ?

[vgrigor]

под масштабируемостью я понимаю следующее:

1- "обычно" - не потеря работоспособности при увеличении обьемов
информации, не сильная потеря производительности,
несложное, наращивание обрабатываемых обьемом при изменении
ключевых параметров производительности CPU, память,
но не диска.
должно происходить пропорционально.

2. под данной проблемой также можно понимать общую оптимизацию
относительно изменения структуры системы так чтобы при ее усложнении, типа -
новые запросы, распределенная работа - все это проходило без проблем.

т.е. большинство непримитивных задач в обычной эволюции распределенной базы данных -

что есть совсем типичная задача как мне кажется.

хотя и сложная конечно.
но везде же такие же проблемы были.

"все решали, но найти общее и сфорулировать как методы - сложно,"
или невозможно?
_______________

или вот вы не слышали истрий (в журналах)
как мы делали жутко-большую базу,
или жутко распределенную базу.
жутко иерархическую, - (ну все как обычно)

слово жутко - полезно для проявления вредностей.
более четкого и явного.

И что в этих случаях было ключевым полезным,
что вредным,
а что обычным - что некритично значит и описывать не надо..