Крупнейший в Республике Беларусь гипермаркет строительных материалов "Баумаркет" от ЗАО "Декорум" (торговая площадь около 7 тыс. кв.м.) сменил систему автоматизации предприятия.
Эксплуатировавшийся ранее известный российский программный комплекс оказался не адаптирован к белорусскому законодательству и не имел необходимой гибкости для решения этой проблемы. Кроме того, сказалось и отсутствие в Беларуси адекватной поддержки ПО.
В качестве альтернативы администрацией гипермаркета была выбрана отечественная разработка "Ветразь-Торговый зал" от НТО "ЛюксСофт" (www.luxsoft.by). Еще одна интересная подробность: благодаря специально разработанной подсистеме конвертации данных из СУБД Oracle замена программного обеспечения была произведена без остановки торгового процесса.
Сергей ДМИТРИЕВ,
dmitriev@kv.by
Комментарии
Страницы
>а поподробнее? что еще за mySQL с транзакциями? это с какой версии мускул оные поддерживает? и где можно посмотреть инфу о том, что яху крутится на мускуле?
Это когда ручками наверное.
Хотя говорят что скоро выйдет. Просто где-то краем уха слышал. Но про ЯХу это полный бред.
http://www.mysql.ru/webboard/index.html?n1=736&n2=2
Жаль, что многие в аРБе еще не знают или знают, но не используют формат таблиц InnoDB и BDB в mySQL при разработке финансовых приложений - например, электронных магазинов.
Про Яху все подробно расписано здесь:
http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.pdf
Про базы данных в 100 Гбайт - никто не спорит, просто в Беларуси таковых нет (точнее, их крайне мало). Вот почему подавляющее большинство офисов белорусских коммерческих банков (и тем более малых предприятий) работает на Clipper и FoxPro под MS/DOS и не очень-то этим озабочено. У них другие проблемы, в первую очередь функциональность (как кто-то на этом йоруме выразился, чтобы кредитные карточки и штрих-коды читались, а покупателю все равно, на какой ОС и СУБД работает продавец). Да и для баз данных в 100 Гбайт существуют куда более эффективные и легкие решения, чем Oracle - например, MS SQL Server, PostgreSQL, mySQL, InterBase. Oracle начинается с терабайтных распределенных баз данных. Нет необходимости покупать 600-м "Мерс" или "Ауди А8" для поездок на дачу или на работу, когда с этим прекрасно справятся пусть не "Москвич", но хотя бы "Мазда".
По пунктам:
>>На Западе Oracle крупные компании покупают для поднятия курса собственных акций
Так обычно говорят люди где-то от кого-то слышавшие, что есть такая штука "фондовый рынок", но понятия не имеющие что это такое. Во-первых, финансовые организации "оптово" скупающие акции (т.е. способные повлиять на цену) в самую последнюю очередь беспокоятся о софте (т.е. вообще их это не е..т) Во-вторых, компании у которых всего один сервак с одним СУБД вообще не идут "public" (то бишь не имеют своих акций -- не доросли еще). У реальных "западных компаний" представленых в индексе Nasdaq как минимум десятки, а то и тысячи (как в случае yahoo) серваков на которых крутятся множество различных СУБД. Вообще как правило внутри крупных корпораций нет единых норм на кампутерные технологии. Разные группы используют разные платформы/языки/СУБД. Именно по этому проблема интеграции у них стоит намного острее и сектор EAI очень хлебный для консалтинговых контор.
Продолжу позже...
Ну здесь ты вообще все смешал в одну кучу. Во-первых, не вводи народ в заблуждение: yahoo выбрал PHP в частности и open-source в целом в качестве приоритетной платформы. Это еще давно на slashdot'e обсуждали. Однако это не значит, что миллионы строк кода мгновенно превратились в PHP. Насчет баз данных, читай внимательно: "replacing some DBM and Oracle with MySQL". Ключевое слово -- some. Потому как предположить миграцию сотен серверов с Oracle на MySQL можно только в кошмарном сне. У них стояли и будуть стоять разные базы. Что касается, наплыва посетителей 11 сентября, то это просто еще раз доказывает, что воюет не танк, а танкист. Т.е. в нашем случае, никакие юмели, дотнеты и ораклы не спасут, если руки из одного места растут. А если команда технически подкована, то и из говна пулю можно сделать.
>>Да и для баз данных в 100 Гбайт существуют куда более эффективные и легкие решения, чем Oracle - например, MS SQL Server, PostgreSQL, mySQL, InterBase. Oracle начинается с терабайтных распределенных баз данных.
Когда говорят с таким апломбом и перечисляют такие списки систем, невольно задаешься вопросом: неужто и вправду человек со всем этим достаточно работал, что имеет возможность делать столь самоуверенные заявления? Неужели действительно строил системы со 100Гб базами в каждой из перечисленных СУБД и утверждает, что какой-нибудь InterBase был быстрее, чем Oracle? Ну предположим. Я таким опытом не обладаю.
Говорю про то что знаю. Я достаточно много работал с парадоксовскими таблицами через BDE интерфейс. Отличная система для каких-нибудь справочников и локальных систем для одного бухгалтера. Отсутствие языка запросов и прочих "наворотов" смотрится вполне органично, пока не возникает задач по конкурентному доступу нескольких пользователей. На InterBase я написал под сотню хранимых процедур. Самое душевное было то, что система работала без проблем на домашнем компе, где оракл непрерывно свопился и не давал никому жизни. Самое забавное, что сервак (т.е. процесс интребасовский) по несколько раз на день заваливался при активной компиляции процедур. И это при сугубо индивидуальном доступе! У нас сейчас 10 девелоперов компилят процедуры на оракловском серваке, а другие 10 спокойно запрашивают из той же базы данные из явашных прог и все это работает мало того, что без сбоев, но и без сколько-нибудь видимого замедления. Вообще за три года работы с ораклом на юниксе, я не разу не видел и не слышал, чтобы он завершился с core dump'ом. Короче InterBase видится мне как глюкавое мини-подобие Oracle. Это особенно очевидно, когда неплохо узнаешь, что такое PL/SQL. После этого язык процедур InterBase'а кажется довольно убогим. Любовь наших программеров к InterBase, как мне кажется, передалась половым путем еще от турбо паскаля посредством делфи.
От mysql'а у меня сугубо положительные впечатления. Главное понимать, как его использовать. Т.е. простая схема, не требующая сложных join'ов, ориентация на чтение данных и сугубо ограниченные апдейты (транзакций нет, хранимых процедур нет, тригеров -- тоже нет). При таком подходе (если он вообще возможен при данной задаче) все может очень быстро работать. Впрочем, если тот же подход применить к ораклу, то все будет еще быстрее. Это отлично работает с большинством сайтов, где данные обновляет один backend'овый процесс (или один пользователь), а все остальные запросы идут только на чтение. На моем личном сайте связка PHP-mySQL тоже доказала свою успешность (всякие там форумы, фотки из базы и прочее)
И последнее. Не надо грузить про терабайты и суперсервера. Все намного проще. Это во времена 32-64 метров памяти на машину, оракл казался нереально тяжелым. Сейчас, когда 512 метров на лаптопе никого не удивляют, никакой видимой разницы между скоростью мускула и оракла на домашней машинке уже не ощущается. Вот специально поставлю дома оракл и сделаю join двух таблиц. Не надо гигабайтов -- тысяч сто записей вполне достаточно. И сделаю тоже самое в мускуле. Посмотрим кто будет быстрее :)
Ну что блин за передергивание! Ораклу в продакшине требуется 1 (один) DBA. Как и для любой другой СУБД. Причем в реальной жизни этот DBA всегда обслуживает несколько серверов. Про "многочисленный штат" это либо для красного словца либо больная фантазия.
Спасибо, что нашли время так подробно прокомментировать мой краткий постинг. Любопытно, что мне совершенно не с чем спорить. Я согласен с Вами по всем пунктам, т.к. высказанные мнения в целом не противоречат моим. Детали не меняют общей картины, а все Ваши конкретные наблюдения по СУБД совершенно справедливы и вполне согласуются с моим личным опытом, особенно по Paradox и InterBase, которые фактически заброшены Borland и, так сказать, доживают свое. Конечно, на них работать не нужно (правда, я и не предлагал). Спасибо Вам за подробный комментарий и отдельное спасибо за то, что обратили внимание, что переход Yahoo не завершен - я этого не заметил, т.к. из их презентации это не очевидно. Разве что по фондовому рынку вынужден с Вами поспорить (я эту науку немного освоил по профессиональной необходимости прямо на Wall Street). Почитайте хотя бы "Финансово-экономический роман" Сергея Голубицкого о крахе Enron, напечатанный в нескольких прошлогодних номерах журнала "Инфобизнес" - см. www.ibusiness.ru. Совершенно захватывающее чтение. Из романа видно, как западные фирмы идут и на другие PR-ухищрения, чтобы поднять побольше шумихи на Wall Street, вызвав поднятие курса акций любой ценой, даже таким странным (с нашей точки зрения) способом, как покупка СУБД.
Про "уверенности не занимать" - так жизнь такая, что поделаешь... За 25 лет в программировании еще не такого насмотришься. Есть опыт работы с базой данных в 700 Гбайт. Привет от родной кафедры, хотя меня _тогда_ на ней еще не было, и нам с Вами, к сожалению, так и не довелось встретиться очно. Как там в Калифорнии? И еще интересно, на каком "железе" стоит Oracle Server, спокойно выдерживающий 10 компиляций одновременно?
Oracle Server -то выдержит одновременно 10 подключений, а тот который домашний и стоит 400$ (где-то) нет. На TUT.by был Access был в начале, то он и 30-ти не выдерживал -падал, а 15 -держал. У меня MySQL и больше держит чем 30-ть.
>>Привет от родной кафедры, хотя меня _тогда_ на ней еще не было, и нам с Вами, к сожалению, так и не довелось встретиться очно. Как там в Калифорнии?
Во какой байнет действительно маленький! Наговоришь грубостей человеку, а он ну почти что знакомый с родной кафедры. Виноват-с, сорвалось :) Привет нашим общим знакомым. При следующем моем заезде (или приезде) я им обещал бутылку хорошей текилы -- вот и познакомимся очно. В Калифорнии тепло и солнечно. Это, кстати, один из немногих штампов "о загранице", который оказался правдой. Капитализм медленно загнивает, зарплаты почти не растут (в лучшем случае), рынок труда очень ужался. К счастью, темпы загнивания потихоньку снижаются. Да и в самом загнивании есть ряд плюсов -- сильно подешевело жилье, и существенно возрос средний уровень коллег по работе. А то раньше брали всех, кто мог расшифровать слово J2EE...
>>И еще интересно, на каком "железе" стоит Oracle Server, спокойно выдерживающий 10 компиляций одновременно?
Это mid-range сервак rp8470 от HP. 4 PA-RISC процессора, 6Gb памяти, операционка -- HP-UX 11i. На этой машинке могут крутится несколько баз и явашных ап-серверов. У нас далеко не гигантская база (что-то около 40 гиг). Скорее фактором выбора полновесной СУБД является сложность обработки данных. Без малого 2 метра кода на PL/SQL просто физически невозможно перевести на какой-нибудь mysql. Вероятно все тоже самое можно было бы делать на DB2 или Sybase. Но на Oracle работает фактор обратной связи -- чем больше систем использует оракл, тем больше специалистов с опытом работы именно на этой СУБД, тем больше ставится ораклов. Про MS SQL Server говорят разные вещи. И что класс и что говно :) Но то что ставить его реально можно только на "wintel" является очень серьезным сдерживающем фактором. У нас между группой разработчиков и серверами -- 1300 миль (серваки в денвере, колорадо). И это удаленность благодаря UNIX (и отличным сетям) нисколько не ощущается. На windows подобного комфорта вряд ли удалось бы достичь.
Про Yahoo основная шумиха была о том, что они перешли с доморощенного yScript'а на PHP. Общественность поражалась от того, что выбор был сделан не в пользу Java. Причем из-за смешной казалось бы причины -- плохая поддержка потоков на BSD. Любители перла переживали за перл. Про mysql как-то вообще не говорили...
Насчет фондового рынка, соглашусь что ради пиара маркетологи идут на многое. И все же это не про Oracle. Устраивать шумиху о том, что используешь оракл, все равно что рассказывать, что пишешь документы в Word'е. Это как бы пример выбора по умолчанию. Вот если компания идет "нестандартным" или новаторским путем, тогда другое дело
2 Инкогнито
Вы очевидно перепутали подключение с компиляцией.
Ты прав. Извиняюсь за невнимальность.
Как я и ожидал, Ваш Oracle Server стоит отнюдь не на РС. Могу только позавидовать. А в Минске, пожалуй, ВСЕ внедрения Oracle сделаны на РС-платформе. Других компьютеров наши предприятия не знают и не желают знать. Представляете, как все медленно работает! Я ж говорил - экономическая диверсия. Из не-РС разве что БМРЦ работает на бэушных mainframe'ах, там вообще до сих пор работают на линейных файлах.
Обязательно почитайте финансово-экономический роман Сергея Голубицкого "Мертвый Левиафан" о крахе Enron в интернете на http://internettrading.net/guru/leviathan/. На www.ibusiness.ru текста нет, он только в бумажном варианте журнала.
Про MS SQL Server по 4-летнему опыту очень близких наблюдений могу сказать только хорошее. Он великолепно держит транзакции (неоднократно имел возможность убедиться в этом на обширном печальном опыте) и шевелится достаточно шустро даже на обычных персоналках. Тот же TUT.BY до сих пор работает на этой СУБД и, кажется, не страдает. Админы ТУТа спокойно керуют серваками со своих рабочих мест по выделенке, и тоже все моментально. (Быстродействие удаленного доступа зависит не от используемой ОС, а от качества связи.) Да и мой бывший американский заказчик с Wall Street держит на MS SQL Server огромную базу данных с финансовой аналитикой и тоже не парится. Простота без излишеств - это все-таки здорово, как и обилие возможностей в такой империи, как Oracle.
Преданность компании Yahoo ОС FreeBSD и мне непонятна. Возможно, это объясняется тем, они пользуются им с 1994 года и не желают расставаться с этим утилем (по сравнению с Linux). Правда, думаю, что они вряд ли сегодня жалеют, что тогда не выбрали Java :).
Когда приедете в Минск с текилой :), передайте, пож., Саше Мелещенко или Володе Абашину, чтобы меня позвали. Если они не поймут, о ком речь, сошлитесь на этот форум. Буду рад познакомиться, наслышан, да и мы с Вами уже годик назад участвовали в одном из бурных форумов на КВ, откуда мне и запомнился Ваш ник.
Страницы