Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » InterBase и FireBird: вопросы по работе и их решение

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

Открыть новую тему     Написать ответ в эту тему

Maximus777

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Уважаемые знатоки! Помогите определиться с концепцией. Суть такая, имеется база действующих клиентов, оформленная в екселевском файле. Что тянет за собой соответствующие проблемы. Файл со временем пухнет. На запись работает только один пользователь и т.д. Желание трансформировать это в полноценную БД всё сильнее. Но, пока не взялся, есть вопросы. Хочется безграбельную БД сделать. У каждого клиента есть масса атрибутов, номер договора, название, сроки, суммы, продукты и ещё вагон инфы. Из неизменяемых данных по клиентам только банковский идентификационный код. Остальное всё не так незыблемо и может изменяться радикально. Мож у кого есть примеры? Мне хотя бы саму структуру БД пока осознать.
И второе, при многопользовательском доступе может возникнуть проблема, когда данные по одному и тому же клиенту могут, одновременно, меняться несколькими пользователями. Каким макаром реализовать уведомление остальным желающим, когда первый пользователь собрался менять данные по клиенту? Что-то типа такого фокуса, Таня открыла карточку клиента "ТОО "Рога и Ботога" и жмакнула кнопку "Изменить данные", после этого Катя делает тоже самое, но ей демонстрируется окошко, что Таня её опередила и надо ждать, пока Таня сохранит изменения

Всего записей: 674 | Зарегистр. 27-07-2007 | Отправлено: 07:40 07-04-2015
ant0ni02004

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Maximus777
блокировка записи в БД: select .... for update

Всего записей: 442 | Зарегистр. 26-10-2004 | Отправлено: 15:15 07-04-2015
OXDBA

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
 Таня открыла карточку клиента "ТОО "Рога и Ботога" и жмакнула кнопку "Изменить данные"

... и резко ушла в декрет,  что делать Кате?

Всего записей: 426 | Зарегистр. 19-01-2005 | Отправлено: 16:17 07-04-2015
Maximus777

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ant0ni02004

Цитата:
блокировка записи в БД: select .... for update

Спасибо.
 
OXDBA

Цитата:
... и резко ушла в декрет,  что делать Кате?

Радоваться. Теперь ей никто мешать не будет.

Всего записей: 674 | Зарегистр. 27-07-2007 | Отправлено: 20:26 07-04-2015
OXDBA

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Радоваться. Теперь ей никто мешать не будет.

Замечательно, вторая попытка. Блокировку кто снимет? И когда?

Всего записей: 426 | Зарегистр. 19-01-2005 | Отправлено: 21:29 07-04-2015
Maximus777

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
OXDBA
Цитата:
Замечательно, вторая попытка. Блокировку кто снимет? И когда?

А! Так у Тани начались схватки и она не нажала кнопочку "Сохранить изменения"? Вот тут бы помог какой-нибудь таймер, который бы через минут несколько сам сохранил изменения.
 
Кстати, кнопка "Изменить данные" может и не блокировать ничего, а просто куда-нить засовывать инфу о том, что такой-то ползатель собирается что-то изменить в данных такого-то клиента. И если следующий желающий полезет в базу с такими же намерениями, то ему напомнить о возможных граблях. Как Вам такой вариант?

Всего записей: 674 | Зарегистр. 27-07-2007 | Отправлено: 10:07 08-04-2015
Shaman2

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
А! Так у Тани начались схватки и она не нажала кнопочку "Сохранить изменения"? Вот тут бы помог какой-нибудь таймер, который бы через минут несколько сам сохранил изменения.  

 
Не сохранил, а отменил изменения. Человек не подтвердил свои данные, кроме того он мог не заполнить обязательные поля и сохранение не пройдет по ошибке с дальнейшей блокировкой записи.
 

Цитата:
Кстати, кнопка "Изменить данные" может и не блокировать ничего, а просто куда-нить засовывать инфу о том, что такой-то ползатель собирается что-то изменить в данных такого-то клиента. И если следующий желающий полезет в базу с такими же намерениями, то ему напомнить о возможных граблях. Как Вам такой вариант?

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

Всего записей: 358 | Зарегистр. 18-07-2003 | Отправлено: 10:48 08-04-2015
OXDBA

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
В общем схватки у Тани и кто-то должен просто выключить компьютер в ее кабинете.

В 99% случаев, пользователи вообще не должны блокировать работу друг друга.
Maximus777
Для начала есть очень хорошая, хотя и очень старая статья Как заблокировать запись в InterBase/Firebird
Правда потом возникнут другие вопросы

Всего записей: 426 | Зарегистр. 19-01-2005 | Отправлено: 11:05 08-04-2015
chAlx

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Для разрешения конфликтов записи самое простое -- запоминать на клиенте время последнего изменения записи, открытой на редактирование. А при попытке сохранения проверять, что текущее время изменений в базе то же, что и было. Если нет -- выводить предупреждение, показывать разницу, звонить начальнику и всё такое, на что фантазии хватит. Если хочется совсем надёжности (обработать одновременные попытки сохранения), то проверку можно сделать внутри транзакции.
 
ПС: Это топик про Interbase или про варианты реализации распределённых клиентов?

Всего записей: 1691 | Зарегистр. 19-03-2003 | Отправлено: 11:09 08-04-2015
OXDBA

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
ПС: Это топик про Interbase или про варианты реализации распределённых клиентов?
 

Мы пытаемся подвести Maximus777 к мысли о том, что Firebird имеет свои особенности реализации клиентских приложений, ибо он версионник.

Всего записей: 426 | Зарегистр. 19-01-2005 | Отправлено: 11:22 08-04-2015
Maximus777

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Shaman2
Цитата:
а потом зависла программа и в базе осталась информация о заблокированной записи. И приехали, без ручного лазания по базе блокировку не снимешь.  

Так не обязательно же там такой лютый ахтунг прописывать.
 
chAlx
Цитата:
Для разрешения конфликтов записи самое простое -- запоминать на клиенте время последнего изменения записи, открытой на редактирование. А при попытке сохранения проверять, что текущее время изменений в базе то же, что и было. Если нет -- выводить предупреждение, показывать разницу, звонить начальнику и всё такое, на что фантазии хватит. Если хочется совсем надёжности (обработать одновременные попытки сохранения), то проверку можно сделать внутри транзакции.

Вот! Особенно последнее предложение, прям в самую суть.
 
OXDBA
Цитата:
Для начала есть очень хорошая, хотя и очень старая статья Как заблокировать запись в InterBase/Firebird

Я уже осознал, что блокировка это зло. Не надо ничего блокировать, надо жить дружно

Всего записей: 674 | Зарегистр. 27-07-2007 | Отправлено: 12:21 08-04-2015
gonkon

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В базе Fireberd 2.5 файл очень вырос. Как бы его уменьшить becap/reestore/

Всего записей: 4 | Зарегистр. 10-06-2010 | Отправлено: 13:30 08-04-2015
tanaseduard



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
gonkon
Однозначно только так.  
Мусор сам не собирается в FB

Всего записей: 518 | Зарегистр. 21-11-2009 | Отправлено: 13:50 08-04-2015
OXDBA

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Мусор сам не собирается в FB

Да неужели? А если sweep interval > 0?

Всего записей: 426 | Зарегистр. 19-01-2005 | Отправлено: 14:02 08-04-2015
tanaseduard



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
OXDBA
И отработает когда происходят массовые update/delete/insert?
Там вроде всегда в конец страницы записывается.

Всего записей: 518 | Зарегистр. 21-11-2009 | Отправлено: 14:14 08-04-2015
OXDBA

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
И отработает когда происходят массовые update/delete/insert?  

При OST - OIT > sweep interval естественно.

Цитата:
Там вроде всегда в конец страницы записывается.  

В смысле? Если ты про фрагментацию страниц, то я этот слух встречал, но видел только фрагментацию BLOB'ами.
 
 

Всего записей: 426 | Зарегистр. 19-01-2005 | Отправлено: 15:02 08-04-2015
tanaseduard



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
OXDBA
 
Подскажи тогда. Если выставлять параметры то размер не будет так расти?
А селективность индексов?

Всего записей: 518 | Зарегистр. 21-11-2009 | Отправлено: 15:04 08-04-2015
OXDBA

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Подскажи тогда. Если выставлять параметры то размер не будет так расти?
А селективность индексов?

Ох... ну и ну...
Если наблюдается резкий рост размера файла БД, при незначительном объеме добавляемых данных, то прежде всего надо смотреть статистику!!! В большинстве случаев Вы увидите резкий разрыв между Next Transaction и Oldest Active, что сопровождается потерей производительности по причине роста TIP,  а не ухудшения селективности индексов. И это никак не связано со сборкой мусорных версий записей т.к. убирать нечего. Далее ищите вредителя, вероятнее всего длительную пишущую транзакцию, в последних версиях FB это элементарно делается через mon$transactions
 
 
Добавлено:
Затем через  mon$attachments.mon$remote_process находите приложение, выпрямляете руки разработчику и наслаждаетесь работой FB.

Всего записей: 426 | Зарегистр. 19-01-2005 | Отправлено: 16:59 08-04-2015
chAlx

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
gonkon

Цитата:
В базе Fireberd 2.5 файл очень вырос.

Насколько я знаю, уменьшаться он не умеет, так что тут только бэкап-рестор. Хотя если размер файла сам по себе не мешает, можно очистить страницы внутри него, чтобы они могли заполняться новыми данными.
 
Примерный сценарий такой:
 
  • удалить лишние данные;
  • отключить лишних клиентов (shutdown) -- если возможно, лучше сделать это пораньше (первым шагом);
  • переподключиться к базе (чтобы старая транзакция, в которой проводилось удаление, не имела шансов числиться активной);
  • пересоздать индексы (какие особенно пухлые, видно в статистике);
  • переподключиться;
  • запустить sweep (я бы его запускал и перед чисткой индексов, но в FB2.5 должно нормально работать и без этого);
  • подключить лишних клиентов (online).
     
    Кстати, всё это, кроме удаления собственно данных (а также многое другое) произойдёт и при бэкапе-ресторе.  
     
    ПС: пример костыля из жизни: для профилактики на частоизменяемой базе (с кучей временных данных) ежедневно выполняется обход всех таблиц (select count(*) from *). Это приводит к очистке практически всех неактуальных страниц, т.к. проводится во время наименьшей активности. Не помню, почему, но этот способ на IB7.5 показал себя более эффективным, чем просто запуск sweep.
     
    ППС: Роста размера файла БД из-за роста TIP не встречал.

  • Всего записей: 1691 | Зарегистр. 19-03-2003 | Отправлено: 19:24 08-04-2015 | Исправлено: chAlx, 22:41 09-04-2015
    OXDBA

    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
     Роста размера файла БД из-за роста TIP не встречал.


    Цитата:
    что сопровождается потерей производительности по причине роста TIP.


    Цитата:
    При включенном автосвипе это приводит к очистке...  

    Хм, странно, кооперативная сборка мусора не должна зависить от значения sweep interval, но за IB ничего не скажу, со времен  IB 5.6 с ним не работал.
    Кстати, а чем был обоснован выбор IB, а не FB?

    Всего записей: 426 | Зарегистр. 19-01-2005 | Отправлено: 21:02 08-04-2015
    Открыть новую тему     Написать ответ в эту тему

    Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

    Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » InterBase и FireBird: вопросы по работе и их решение


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.B0ard
    © Ru.B0ard 2000-2024

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru