Мобильная версия форумов
Открыть
 −12°C
завтра: −15°C
Погода в Перми
−12°C
ночью−16°C
утром−20°C
завтра−15°C
Подробно
 66,25
−0.4574
Курс USD ЦБ РФна 19 февраля
66,2470
−0.4574
 74,91
−0.3437
Курс EUR ЦБ РФна 19 февраля
74,9055
−0.3437
  • Юный_програмер

    Анонимный пользователь

    Пока я ламак в этом :o, но очень хочу стать профи :спок:.
    Хочу сделать так чтоб два компа соединенные напряму через сетевухи (ОС винды XP на обоих) работали вместе над одной субд. Всё сделать хочу при помощи подручных средств, с ораклом наверное не получится так как поди не смогу его установить и взять дистрибутивы, имхо лучше взять в качестве субд какой-нибудь MS-accesse.
    Клиент-серверное приложение для обработки бд забабахать на с++ (VS или builder) пока не знаю .
    Посоветуйте, плиз? :шок: Реально ли такую приблуду забодяжить или есть методы покруче? :eek:
    Как на другом компе будет видеть бд, которая в odbc первого компа? :а\?: Я типо такого делал через оракл, но там все было разрулено специалистами, и с разных компов обращались к бд, вводя свои логины и пароли, а вот как с accessom через odbc?
    А если при таком прямом соединении не проконает, то через нормальную локалку хотябы как делать, или разницы нет? :безум:
    Короче вопросов тьма, в голове тьма, токо ваши светлые головы смогут просветить меня, помогите плиз! :bottle: :live: :pivo: Или книги посоветуйте, где как раз мой случай - построение клиент серверных приложений для субд используя локалку :а\?:

  • member

    Сообщений: 60

    Ну аксес конечно штука хорошая, но это не технология клиент-сервер.
    Лучше посмотри на Interbase/Firebird или MS SQL

  • veteran

    Сообщений: 1901

    еще можно заюзать 1С ... там уже все готово, тока пиши свою БД и пиво попивай :pivo::улыб:

  • Анонимный пользователь
    В ответ на: Ну аксес конечно штука хорошая, но это не технология клиент-сервер.
    Лучше посмотри на Interbase/Firebird или MS SQL
    судя по вопросу, посмотреть надо вначале в книгу, имхо

  • activist

    Сообщений: 382

    В ответ на: Клиент-серверное приложение для обработки бд забабахать на с++ (VS или builder) пока не знаю .
    Однозначно Builder. Visual для этого мало подходит. Ну а по поводу формата-- MS SQL имхо.

    Отсутствие вариантов – тоже вариант, но самый худший.

  • рыжий котэ

    Сообщений: 12083

    На счет MS SQL не согласен. Interbase рулит однозначно в план устойчивости и надежности.

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • Анонимный пользователь
    В ответ на: На счет MS SQL не согласен. Interbase рулит однозначно в план устойчивости и надежности.
    InterBase (Firebird) "рулит" в плане экономичности.
    Причем, как финансовой, так и машинных ресурсов.
    СУБД корпоративного уровня (мускул, например) в плане отказоустойчивости порядково обходит InterBase.
    Но вопрос в том, стОит ли ставить такого монстра для того, чтобы просто понять принципы построения механизмов взаимодействия клиент-сервер.

  • Максимыч

    Анонимный пользователь

    По моему опыту -
    Бери Builder или Delphi (с точки зрения работы с БД это моноедино) и FireBird (честный бесплатный сервер без ограничения числа юзеров и подключений)
    Пока объем БД не приблизится к Гб этого хватит выше крыши. Надежность, при минимальном присмотре, достаточная. Вопросы в приват.

  • Анонимный пользователь
    В ответ на: По моему опыту -
    Бери Builder или Delphi (с точки зрения работы с БД это моноедино) и FireBird (честный бесплатный сервер без ограничения числа юзеров и подключений)
    Пока объем БД не приблизится к Гб этого хватит выше крыши. Надежность, при минимальном присмотре, достаточная. Вопросы в приват.
    объем какую роль играет?
    почему именно Гб?

  • member

    Сообщений: 60

    объем какую роль играет?
    почему именно Гб?


    Потому, что на больших объемах у IB могут начинаться странности и тормоза. Но в принципе это завист от задачи. Если у тебя просто тупое хранилище, из которого делаются выборки и почти нет вставок, то объем может быыть любым. (до тех пор пока будет устраивать скорость доступа)

  • Анонимный пользователь
    В ответ на: объем какую роль играет?
    почему именно Гб?


    Потому, что на больших объемах у IB могут начинаться странности и тормоза. Но в принципе это завист от задачи. Если у тебя просто тупое хранилище, из которого делаются выборки и почти нет вставок, то объем может быыть любым. (до тех пор пока будет устраивать скорость доступа)
    "тормоза" возникают по многим причинам.
    главная - неграмотно сроектированная структура БД.
    пресловутый Гб никакого отношения к производительности не имеет.
    Firebird 1.0. БД: 50-80 тыс. записей в день, регулярные статистические срезы, проводимые по текущему объему набора данных в базе. Размер > 3Гб. Т.о. грамотно (что в случае с IBase, FB - не сложно) настроенный сервер и продуманная структура метаданных - залог производительности.

  • Анонимный пользователь
    Позволю себе несогласиться.
    1. у IB очень слабый оптимизатор запросов. Поэтому для нормальной работы на больших объемах приходится в запросах явно прописывать планы исполнения, что создает дополнительный геморой при поддержке системы.
    2. при большом количестве параллельно работающих пользователей активно вставляющих/меняющих данные - у механизма версионности иногда возникают проблемы. Начинают копиться старые версии записей.
    3. Я не говорил, что при объеме 1 ГБ все должно умереть. Мне самому приходилось разрабатывать, сопровождать и развивать БД на базе IB объемом порядка 2 - 3 ГБ. Да, они работоспособны. но получение статистического отчета на таких базах требует довольно много времени. Например отчет по оборотам склада (суммарные обороты на начало периода, детализация за период, суммарные обороты на конец периода, помоему еще что-то в него входило, сейчас все не вспомню) на БД объемом 2 ГБ занимал 28 минут. На БД объемом около 300 мб - несколько сотых секунды. так что с ростом БД - скорость к сожалению падает не линейно.
    4. Я знаю о существовании БД объемом 200-400 Гб поддерживаемых IB, но это простые хранилища. В них почти нет вставки и 95 % этих БД - занимают блобы. Так что все работает, но просто кадый инструмент предназначен для решения своих задач.
    Ваша система - вывзывает уважение, но все же рекомендую подумать о переходе на другие сервера. Например MS SQL.
    При объеме вставки 50-80 тыс. записей в день - ваша БД должна набирать около 2 ГБ в год. Если это не тупой биллинг, собирающий инфу от железа, то через год - два у вас начнутся проблемы, независимо от архитектуры.

    Еще один момент, надеюсь вы уже сделали свою БД многофайловой? Далеко не все версии IB способны работать с файлом БД объемом более 4 ГБ под виндой. И проблемы могут возникнуть гораздо раньше.

  • Анонимный пользователь
    1. "Очень" - категория не количественная, потому не представительная.:улыб:Да, иногда серверу приходится явно указывать план в запросе. Да, очень неприятно. Но это запланированные и учтенные потери. А, коли предупрежден, то - Вы знаете.

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

    3. "что с ростом БД - скорость к сожалению падает не линейно." Подобных замеров ни на Oracle, ни на MSSQL не проводил. На этих СУБД зависимость линейна?
    Да, операции зависящие от всего набора записей, увы, весьма ресурсоемки (и дисковое пр-во и загрузка cpu). Показатели: от 15 до 40 минут (в зависимости от загрузки сервера БД другими задачами).
    Но то же самое можно сказать и применительно к корпоративным СУБД. Разве что, конечно же, градиенты перечисленных показателей будут порядково более скромнее.:улыб:Но, Вы же помните, что, выбирая IBase/FB, мы выбираем экономию. Посему - миримся пока это не критично и, как справедливо Вами было отмечено, переходим на более мощную серверную платформу, если "так дальше жить нельзя".

    4. Безусловно.

    Пока что переход не обоснован. Ресурсоемкая задача - всего одна и, как Вы понимаете, переводить довольно-таки большое кол-во БД и, соответственно, править клиентские АРМы под другую платформу просто невыгодно.
    Информация, содержащаяся в заявленной мной БД, актуальна в контексте года. Т.о. 1 год - 1 база.
    Старые БД - в архив.
    FB стоит на Linux (надежнее и производительнее, нежели под Вин, имхо). БД, конечно же, многотомная, ибо, как оказалось, наш LI-T6.2.796 FB 1.0 отказывается узнавать БД, если размер тома >=2Гб (именно FB, т.к. ядро системы проапдейтили до поддержки файлов рамером 4Гб).

  • member

    Сообщений: 60

    Рад, что мы всетаки сошлись во мнениях.:)

    По пункту 3 - к сожалению небыло возможности погонять это на оракле или MS SQL. БД сохранилась до сих пор, но для эксперимента придется не только перелить данные, но и сделать процедуру формирующую отчет. А потом еще для полной чистоты эксперимента - ее заоптимизировать настолько, насколько была заоптимайзена процедура в IB.
    А времени на это увы - жалко.

    Я собственно и не агитирую "Всем переходить на ...":улыб:
    Я просто указал возможные источники проблем для вашего случая. Рад, что вы с ними уже разобрались.

    Желаю удачи.

  • Анонимный пользователь
    В ответ на: Еще один момент, надеюсь вы уже сделали свою БД многофайловой?
    а как это делается?

  • Анонимный пользователь
    это и многое другое:www.ibase.ru + Востриков, Ковязин "Мир InterBase"

Записей на странице:

Перейти в форум

Модератор: