Top.Mail.Ru
Последняя информация о COVID-19

Модернизация СУБД

Данные в компании хранятся с использованием технологии DBF. Эта технология устарела. Какие варианты по модернизации СУБД Вы можете предложить? Заранее спасибо

436
Комментарии (38)
  • 3 декабря 2009 в 13:07 • #
    Михаил Зырянов

    Роман, пожалуйста, расскажите немного о Вашей компании: чем занимается, какие данные хранятся в DBF, каков объем, какова частота транзакций, много ли пользователей, много ли одновременных пользователей, есть ли удаленные пользователи, есть ли территориально удаленные площадки, что хотите получить в результате модернизации СУБД и пр. - все, что может быть важно при выборе модернизации СУБД. Это поможет Вашим коллегам дать более точные ответы.

  • 3 декабря 2009 в 15:59 • #
    Денис Тучин

    Поддерживаю, Михаила.
    Роман, если вы скажете какой общий объем данных, сколько записей в таблицах, сколько обращений к базе в единицу времени (на чтение/на запись) и т.д., то можно будет подобрать наиболее эффективное решение для вашей задачи.

  • 3 декабря 2009 в 21:08 • #
    rrr rrr

    Денис, они "сидят" на DBF базе, этим все сказано. Не важно сколько записей, сколько пользователей, какая нагрузка и т.д., любое адекватное решение будет на порядок лучше чем, то что есть. В данном случае, можно в слепую сказать: "Если СМОЖЕТЕ переходите на MS SQL и будет вам счастье".

  • 4 декабря 2009 в 12:49 • #
    Михаил Алексин

    4 транзакции в день можно вполне адекватно вести в *.txt

  • 4 декабря 2009 в 13:29 • #
    rrr rrr

    В этом случае не было бы желания что-то менять.
    Я не вижу особой разницы между dbf и txt, ИМХО это одно и тоже :)

  • 4 декабря 2009 в 13:41 • #
    Михаил Алексин

    Пока озвучена только одна предпосылка причем весьма сомнительная - эта технология устарела.
    Сразу возникает вопрос - устарела для чего?
    Существует ли реальная бизнес-потребность в модернизации?

  • 4 декабря 2009 в 13:43 • #
    Михаил Алексин

    Не верное ИМХО. Даже с точки зрения технологий неверное.

  • 4 декабря 2009 в 15:43 • #
    rrr rrr

    Михаил, мы смотрим с разных точек зрения.
    Вы смотрите различия с точки зрения реализации (наличие индексных файлов, шапки, ограничений по спецификации на DBF и т.д) я смотрю на это с точки зрения (отказоустойчивости, производительности, ограничения по блокировкам и т.п.).
    Да вы можете сказать, что индексы позволяют повысить производительность системы на чтение и отбор записей, но тоже самое можно сделать и в txt файле, а текущая производительность серверов сведет к минимуму различия по скорости позиционирования внутри структуры с использованием двоичных данных и символьных. Доступ же к данным с использованием ODBC не намного отличается в одном и в другом случае, в любом случае будут тормоза :).

    Ну вот пришла идея, а ведь реально, если у Романа используется доступ к базе через ODBC, то вопрос о переходе на другой формат можно решить простым переключением источника на другую библиотечку, например на ту же TXT или в крайнем случае на SQL :).

  • 10 декабря 2009 в 13:01 • #
    Евгений Полубабкин

    Ну вот пришла идея, а ведь реально, если у Романа используется доступ к базе через ODBC, то вопрос о переходе на другой формат можно решить простым переключением источника на другую библиотечку, например на ту же TXT или в крайнем случае на SQL :).

    Это как? просто перенастроить источник на Oracle и надеятся что сразу вырастит производительность ?
    Бред.

  • 10 декабря 2009 в 17:04 • #
    rrr rrr

    Евгений, причем тут Oracle, при чем тут производительность? Внимательней читайте и не выдергивайте из контекста... В этом ответвлении обсуждение идет всего лишь о dbf и txt... :)

  • 4 декабря 2009 в 12:54 • #
    Денис Тучин

    Бесспорно "любое адекватное решение будет на порядок лучше чем, то что есть", но это не повод выбирать какое попало решение.
    Возможно, подойдет БЕСПЛАТНОЕ ПО.
    А, возможно, ПЛАТНОЕ.
    В обоих случаях тоже есть варианты.
    Естественно, при выборе платного хочется выбрать такое которое не нужно будет менять через пару лет.
    Хотя и на замены бесплатного тоже приходится не мало трудозатрат

  • 4 декабря 2009 в 13:44 • #
    Михаил Алексин

    Денис, фишка в том, что использование того что есть, может быть наиболее адекватным решением.

  • 4 декабря 2009 в 16:22 • #
    Денис Тучин

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

  • 4 декабря 2009 в 14:46 • #
    rrr rrr

    Предлагая MS SQL я руководствовался следующими идеями:

    1. Смотрим историю развития форматов БД и самих БД. В свою бытность большинство разработчиков переписывали свои разработки с DBF структур на SQL, это было "модно" и конкурентноспособно. Как следствие, если "живы" разработчики, то с большой вероятностью будет в наличии и SQL версия.
    2. Скорей всего, чтобы поддержать общею производительность, базу несколько лет просто "режут" и за счет этого она еще функционирует. Соответственно при переходе можно получить бизнес требование сохранение всей истории в одном месте, с доступом к анализу. Соответственно дальнейшая задача создание блока анализа. Для SQL найти приложение проще нежели на бесплатном софте.
    3. Поддержка, наличии информации и качество документации, наличие специалистов - под SQL не проблема.
    4. Решение вопроса повышения отказоустойчивости и снижения рисков потери данных.
    5 :) И основная мысль, запрос делает Директор по ИТ: соответственно человек понимающий сколько и какой информации нужно дать для получения необходимого ответа/помощи, поэтому остальные нюансы принимаем как не существенные, и считаем, что именно поэтому Роман их и не озвучил. Всякое может быть, например: У Романа сидят 3 разработчика, которые писали эту систему и сейчас им все равно к чему цеплять ее, они одинаково не знают ни SQL, ни Oracle, ни DB и т.п. Главное, для них, чтобы следующим летом не вызывали из отпусков, что надо восстанавливать битый dbf файл. :) Поэтому в данном случае мы не ищем оптимальное решение, а подбрасываем монетку и в путь.

  • 4 декабря 2009 в 16:15 • #
    Михаил Алексин

    Коллега, я предпочитаю не высасывать новые сущности и предпосылки из пальца:
    1) Я не знаю такого - SQL структура, я такой язык знаю и знаю что он имеет отношение к реляционным БД, коей кстати является и Paradox и FoxPro хранящие данные в файлах формата dbf.
    2) Чтобы поддержать общую производительность приходится точно также резать, разносить по репликам и городить кластеры для MSSQL/Oracle/DB2
    3) По dbf проблема еще меньшая, "лабать на клиппере" обучен каждый второй бухгалтер в возрасте в районе 40. Фокспро знакомо двум из трех студентов технического вуза.
    4) Это у Вас видать транзактлог не улетал ни разу. Поверьте мне, реиндексинг дбф - цветочки. Так что бэкапы, бэкапы и еще раз бэкапы. А также репликации.
    5) "Не все йогурты одинаково полезны". Единственной озвученной предпосылкой было моральное устаревание технологии. Это бред а не повод менять работающее решение. Терпит ли компания какие-либо убытки от устаревания технологии? В каком объеме? $3000 - терпите дальше это самый экономически эффективный способ решения проблемы. $300000 - выбирайте что вашей душе угодно, уносите выбранное в ДЦ "пять девяток", на оставшиеся пейте пинаколаду в канкуне.

  • 4 декабря 2009 в 17:27 • #
    rrr rrr

    Михаил, давайте не будем обобщать :).

    1. Если вам не нравится слово "структура" можете заменить на, что угодно, мне фиолетово, тем более оно не несет для вас никакой смысловой нагрузки. НО все же может будет интересно -
    http://www.williamspublishing.com/Books/5-8459-0912-0.html

    2. Мы говорим про компанию, в которой данные хранятся в DBF файлах, если вы при том же объеме вы режете MSSQL/Oracle/DB2, то возможно, что не совсем правильно построена архитектура вашей БД.

    3. Не подтвержденное высказывание. Среди знакомых бухгалтеров таких нет (есть знающие с , 1С, но вот знающие клиппер нет), студентов на критичные узлы даже не рассматриваю.

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

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

    Михаил, есть уровни/ступени развития организации и не важно в каком направлении, продажи или ИТ, главное нельзя скакать через ступени, можно очень сильно упасть, поэтому можно с некоторой долей вероятности утверждать, что для данной компании ДЦ в 5 девяток в течении нескольких лет не светит даже на горизонте. Поэтому точнее будет сказать: "Не все йогурты одинаково доступны".

  • 4 декабря 2009 в 18:56 • #
    Михаил Алексин

    Странные вы умозаключения делаете. Как-то не вяжется это с вашим пристрастием к фиолетовому цвету=)
    Структура MS SQL Server для меня имеет таки значение.
    Хотя Дмитрий, давайте не будем переходить на личности и меряться длиной ..... опыта конечно.
    По другим пунктам, готов дискутировать в других ветках. Здесь смысла не вижу=)

    А что касается замены dbf в связи с устариванием, поменяйте на нерялиционную БД. Относительно новая технология, огромные перспективы, свободная лицензия...=)

  • 4 декабря 2009 в 23:03 • #
    rrr rrr

    >>А что касается замены dbf в связи с устариванием, поменяйте на нерялиционную БД.

    Михаил, я ценю ваши разносторонние знания по БД, а так же надеюсь если мне понадобится помощь/консультация по семантическому моделированию (тут у меня пробел, а скорей всего через несколько месяцев может понадобится), то смогу к вам обратиться... :)

    PS По поводу дискуссий и смысла жизни... Согласен, тут, смысла нет, а в других ветках будет интересно/полезно пообщаться.

  • 7 декабря 2009 в 10:20 • #
    Михаил Алексин

    Обращайтесь, Дмитрий.
    Правда некоторое время назад я, так сказать, сменил ERWin на Power Point=)
    Но думаю что есть еще порох в пороховницах.

  • 10 декабря 2009 в 12:59 • #
    Евгений Полубабкин

    :-) еще один не правильный ответ.
    почему MS SQL? Скорее всего Ваш ответ на этот впрос будет "Потому что я его знаю".
    почему не interbase? Oracle или что то еще?

  • 10 декабря 2009 в 14:51 • #
    Михаил Алексин

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

  • 10 декабря 2009 в 17:52 • #
    rrr rrr

    :) Ну вот и дельфисты подрулили....

    Для более менее точного ответа на вопрос Романа мало информации, в общем то Михаил уже ответил по этому поводу.

    Мой ответ же базировался на истории развития отрасли и вероятностей того или иного принятия решения компаниями, которые занимались разработкой ПО для управленческого учета, модой на те или иные направления, противоборства которые идут с девяностых и т.д..
    Евгений, в основном мы делаем только первый выбор, дальше нас ведут/развивают в том направлении, в котором выгодно крупным игрокам. Я не знаю помните или нет ажиотаж в форумах, когда появились исходники InterBase молодые радовались, а те кто на этом бизнез строил и разрабатывал ПО начали стрематься, так как было не понятно куда это заведет и к чему такой шаг, вот тогда компании и заложили у себя в планах смену базовой платформы, и конечно посмотрели в сторону Oracle. Ну не в сторону же MS смотреть, да, Евгений? :) Да нет это нормально, интересно сейчас в форумах идет обсуждение, что круче MS VS или дельфи?

    Вот ответьте, предположим вы программист на Дельфи (думаю вам это ближе), вам необходимо разработать БД для малого предприятия, что вы выберете interbase или dbf?

  • 10 декабря 2009 в 18:12 • #
    Михаил Алексин

    Interbase без вариантов, просто чтоб не мучится с BDE=)

  • 10 декабря 2009 в 18:47 • #
    rrr rrr

    Михаил, точно так же ответят 70-80 % дельфистов... :) И поставят серверную СУБД под небольшую нагрузку, просто потому, что рука на этом набита и так проще. И именно поэтому я предположил, что у Романа система написана не на дельфях, и дальше в таком же духе, не забывая про VFP...

    Если бы в условии было требования разработка с использованием MS VS, то для малого предприятия была бы выбрана dbf, а для средней и крупной компании MS SQL.

  • 10 декабря 2009 в 19:30 • #
    Михаил Алексин

    В случае с MS VS 70-80% станут использовать MSDE и будут правы.
    dbf действительно устарела, ровно настолько, чтоб не пускаться в разработку нового продукта с его использованием.

  • 3 декабря 2009 в 16:04 • #
    Михаил Алексин

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

  • 3 декабря 2009 в 16:13 • #
    Dmitry Kuznetsov

    Роман, а используемые Вами приложения смогут работать с другими СУБД? Что-то мне подсказывает, что и приложения Вам придется менять.

  • 3 декабря 2009 в 18:56 • #
    Михаил Алексин

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

  • 5 декабря 2009 в 12:20 • #
    Андрей Мельников

    Друзья коллеги!
    Спор был у Вас ни о чем. Сейчас просто модно менять dbf на SQL но для чего это делать никто не знает. У нас базы за несколько лет и они на dbf и менять на SQL я точно не собираюсь. Как правильно сказал коллега - вы не знаете что такое когда летит транзаклог - по мне так лучше стандартными средствами восстановить индексы и базу чем медленно сходить с ума. Скорость работы когда 50 пользователей ни чем не отличается в обоих технологиях.

  • 7 декабря 2009 в 10:30 • #
    Михаил Алексин

    Почти +1000. Единственное я бы сформулировал несколько по другому:
    - Бизнес на данный момент не предъявляет требований, которые могли бы быть проще/дешевле/эффективнее с помощью SQL Server

  • 7 декабря 2009 в 10:57 • #
    Андрей Мельников

    Согласен на все 100 с такой формулировкой.

  • 7 декабря 2009 в 12:21 • #
    rrr rrr

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

  • 7 декабря 2009 в 12:26 • #
    Михаил Алексин

    Дмитрий, да не забыли, потеря данных закрывается в случае dbf ровно так же как в случае MS SQL. Единственное что проще - built in репликация.
    Риски либо такие же, либо сравнимые.

  • 7 декабря 2009 в 12:22 • #
    rrr rrr

    Скорость в сиквеле при 50 пользователей ниже.

  • 11 декабря 2009 в 00:47 • #
    Vladimir Elizarov

    Можно линки на бенчмарки dbf vs sql на 50 пользователей? :)

    Интересно.

  • 11 декабря 2009 в 14:25 • #
    rrr rrr

    Владимир, как вы себе это представляете, солидная компания проводит официальный тест на производительность ФС и КС БД? Если и остались такие ссылки, то где-то в глубоких архивах. На этапе выхода на наш рынок...
    Поэтому только собственный опыт. Если убрать в сторону 1С тесты, то:

    В конце девяностых была задача по интеграции с немецкой специализированной БД, тогда тестировал несколько СУБД в том числе и ФС БД на dbf.

    В 2003 или 04 пригласили проконсультировать по задаче похожей с Романовой, самописка (программист был еще доступен) с лохматых годов интегрированная с 1С бухгалтерией. Тогда мой вердикт был простой: нужен перехода на 1С, нежели переключение самописки на SQL. Дальше обоснование за счет чего и каких процессов. В общем если кратко, люди не поверили решили проверить, в очередной раз подтвердилось, что без изменения логики, простым переключением на SQL кроме надежности более ничего не получить, ну да можно было залить историю с прошлых лет, но бизнесу этого было не нужно. Приложение рук к SQL да дает эффект, но он гасится через усиление железа (конечно до определённого уровня). В результате программист предложил переписать самописку под SQL с учетом моих рекомендаций по выпрямлению процессов, но окончательное решение было принято в сторону 1С. Сразу скажу внедрял не я :).

  • 11 декабря 2009 в 00:46 • #
    Vladimir Elizarov

    Господа. Вам не кажется скорость работы базы во многом зависит от кого насколько она хорошо спроектирована, реализации SQL-сервера, от характера данных и условий использования базы? На глазок и не скажешь.