|
v7: С какой максимальной по размеру и стабильно работающе базой DBF вы сталкивались? | ☑ | ||
---|---|---|---|---|
0
maxnn
10.04.12
✎
22:53
|
Щас просто стоим на распутье, куда идти.. Либо сворачивать либо SQL. Главный аргумент сторонника SQL - это то что все крупные организации работают на SQL.
Так вот. Для статистики, какой размер стабильно работающей базы вы щупали? |
|||
1
YF
10.04.12
✎
22:54
|
опять про пиписьки ...
|
|||
2
ОбычныйЧеловек
10.04.12
✎
22:54
|
(10) Если просто перейдете на СКЛ (без прямых запросов) - работать будет тормознее чем на дбф (причем значительно тормознее)
|
|||
3
ОбычныйЧеловек
10.04.12
✎
22:55
|
(2) -> (0)
|
|||
4
andrewks
10.04.12
✎
22:56
|
у людей и по 10-15 гиг базы вертятся. тут главное - грамотное построение и закрывающиеся регистры
|
|||
5
Злопчинский
10.04.12
✎
22:59
|
(2) не обязательно... фарм база крутилась у меня на скуле - каких-либо принципиальных тормозов по сравнению с дбфной В ОПЕРАТИВНОЙ работе - вроде не было. Проблема была только с замедлением группового перевпровдения доков (ибо скуль2000) - но мну это было некритично.
. скуль - это стабильность. на дбфе сделать возможноть горячих бэкапов с минимальной периодичностью - я не знаю... |
|||
6
Злопчинский
10.04.12
✎
23:00
|
(4) присоединяюсь.
база за 4 гига работала в принципе так же быстро как и в размере полтора гига. объем запрашиваемых итогов - от размера базы не сильно зависит. |
|||
7
ОбычныйЧеловек
10.04.12
✎
23:01
|
(5) >>Проблема была только с замедлением группового перевпровдения доков...
Про это и говорил - для некоторых без перепроведение никуда... |
|||
8
maxnn
10.04.12
✎
23:03
|
(7) Вот и у нас. В конце каждого месяца, мы месяц перепроводи раз 5, а в конце квартала весь квартал.
За ночь у меня проводится полтора - два месяца. |
|||
9
maxnn
10.04.12
✎
23:04
|
(2) В чём сложность перехода на прямые запросы?
|
|||
10
ОбычныйЧеловек
10.04.12
✎
23:04
|
(8) при переводе на скуль будет перепроводится за ночь полмесяца... зато есть шанс перевести все на прямые запросы и тогда все будет летать..
|
|||
11
ОбычныйЧеловек
10.04.12
✎
23:05
|
(9) нету сложности - нужно 2 вещи - время и деньги.
|
|||
12
Злопчинский
10.04.12
✎
23:07
|
(9) это другой уровень компетенции
(10) отчеты/обработки на скуль переписать - особо проблем нет, просто вштырить как следует, да и ОТЧЕТЫ - НЕПРИНЦИПИАЛЬНО. . а вот если перепиливать алгоритмы проведения - там прсото возможно ПЕРЕПИСАТЬ придется много, просто ТУПО ТЕХНИЧЕСКИ много переписать. . но и этого в принципе можно избежать. при перепроведениях - основной тормоз временный расчет на заднее число. Если от него избавиться, то вообщем и без прямых запрсоов мжно жить. |
|||
13
Sh1ko
10.04.12
✎
23:07
|
(10) reconnectnative() ?
|
|||
14
maxnn
10.04.12
✎
23:11
|
(12) Вот с задним числом у нас проблемы.... залазить на 1-2 месяца назад и править, у нас обычное дело... И это никак нельзя побороть.. специфика организации такая.
|
|||
15
ProProg
10.04.12
✎
23:12
|
шо еще остались неудачники работающие на клюшках на дбф базах?
|
|||
16
ОбычныйЧеловек
10.04.12
✎
23:17
|
(13) это в первую очередь (но на сколько я помню проблема не только в этом)
(15) неудачники на устаревшей 7ке - успешные на высокотехнологичных продуктах от субсистем - это азы и мы их знаем и помним. |
|||
17
shag008
10.04.12
✎
23:20
|
(5) есть, урбд называется
|
|||
18
Злопчинский
10.04.12
✎
23:25
|
(15) иди нафиг с нашей аллейки... окучивай неудачнегов
|
|||
19
Злопчинский
10.04.12
✎
23:27
|
(14) ПИ..Ж! забороть можно, надо только чтобы это было ДЕЙСТВИТЕЛЬНО НУЖНО.
а так - если исправленяи задним числом идут только в увеличение КОЛИЧЕТСВА на складах - то перепроведение ЗАВЕДОМО будет успешным. и можно даже в фоновом режиме перепроводить в рабочее время... потихоньку.. по 1-2-3 дока... |
|||
20
Злопчинский
10.04.12
✎
23:28
|
(17) пока что никто мне внятного ответа не дал: куда пишутся действия в базе (по вводу и првоедению документов) в тот момент когда идет выгрузка в УРБД...
|
|||
21
maxnn
10.04.12
✎
23:30
|
(19) Проводить в рабочее время без переноса ТА?
|
|||
22
shag008
10.04.12
✎
23:32
|
(20) выгрузка-загрузка УРБД - это вроде как транзакция
т.е. изменения объектов либо до, либо после выгрузки |
|||
23
йцукецоп
10.04.12
✎
23:32
|
за перепроведение полтора мес расстреливать - все рещается управленчески
|
|||
24
Злопчинский
10.04.12
✎
23:32
|
(21) все зависит от ЧАСТНОСТЕЙ, как говорится если хрен дубовый, да дуб хреновый...
|
|||
25
Злопчинский
10.04.12
✎
23:33
|
(22) и что, у меня складской сборщик будет стоять и ждать...? идите в то место, откуда мы все появились, стакими советами...
|
|||
26
shag008
10.04.12
✎
23:35
|
(25) да уж....
а что мешает делать обмены каждые 10 минут допустим? файлы мизерные...занимает всё это 1-3 сек. |
|||
27
shag008
10.04.12
✎
23:35
|
+ 26
и у тебя всегда почти актуальная переферийка |
|||
28
Злопчинский
10.04.12
✎
23:39
|
(26) данный вопрос ранее уже поставлен в очередь решения, как один из представляющих интерес. Все будет определяться, сколько именно база будет стоять в транзакции при выгрузке.
|
|||
29
йцукецоп
10.04.12
✎
23:40
|
(27) когда к тебе менегеры придут за деньгами которые онм потерялм изза урбд ты изменишь свое мнение
|
|||
30
shag008
10.04.12
✎
23:43
|
(29) сбои есть у всех систем
у УРБД их не больше чем у остальных |
|||
31
Злопчинский
10.04.12
✎
23:43
|
(290 тема не раскрыта!
|
|||
32
shag008
10.04.12
✎
23:46
|
(28) всё зависит от объема обмена
если перепровелся документ в пару тысяч строк, то подольше конечно а для доков в 10-30 строк - это всё быстро происходит |
|||
33
Злопчинский
10.04.12
✎
23:48
|
(32) у меня доки по 300-400 строк - в порядке вещей. но что плюс - все работают только в ТА, и за 10 минут 4 манагера суммарно могут доков навводить тысч на 5 строк...
|
|||
34
йцукецоп
10.04.12
✎
23:49
|
(31) была у меня неприятная история когда закуп в юсд шел урбд стояла, менегеры удаленно сидели и в заказах партии подбирали так как от маржи их зп зависила ...дальще рассказывать ?
|
|||
35
shag008
10.04.12
✎
23:52
|
(34) мы говорим сейчас о бекапе
т.е. переферийная база-приемник только получает данные в ней никаких изменений не ведётся |
|||
36
shag008
10.04.12
✎
23:54
|
(33) секунд 10-15 на выгрузку
зависит от компа |
|||
37
maxnn
10.04.12
✎
23:55
|
(23) Ну иногда это бывает из-за непреодолимых обстоятельств. Например самое распростронённое у нас - это поступление импорта. Допустим идёт 4 контейнера, партия одна. После таможни один контейнер уже разгрузился у нас и всё продали с него, второй контейнер только разгружается, третий контейнер в пути от таможни, а четвёртый контейнер ещё на таможне может или 1 день простоять или 1 месяц. А себестоимость всей партии точно можно узнать только когда растаможится последний контейнер. Так вот все доп расходы ложаться в эту партию и заносятся только когда будет разгружен последний контейнер, а порой проходит больше месяца. Вот задним числом эти данные и вбивают.
|
|||
38
Злопчинский
10.04.12
✎
23:55
|
(36) понял, все на серваке - должно по идее быстро быть...
|
|||
39
shag008
10.04.12
✎
23:56
|
+36
у меня выгрузка за день (это около 3000 доков с движениями по 2-3 регистрам) проходит секунд за 20-30 |
|||
40
shag008
10.04.12
✎
23:57
|
+39
среднее количество строк в документе - 25-30 |
|||
41
Злопчинский
11.04.12
✎
00:00
|
> вот все доп расходы ложаться в эту партию
- где-то у вс что-то в консерватории неправильно... . если право собственности переходит к вам после растаможки - то это все отдельные партии и нехрен ждать чего-то и правит задним числом - вводим/приходуем по факут . если право собственности переходит к вам по факту отгрузки за рубежом - то доп расходы - по каждой ГТД шке кладутся отдельно, затраты на перевозку - или целиком на партию или на конкретную часть партии если контейнеры довозятся... . ну фиг с ним. .проще сделать чтобы допрасходы падали текущим временем - хоть на всю hgfhnb.? хот ь на ее часть.. да.. но тут вылазит бухия.. которая это все может поломать... . короче - смотреть надо.. м.б. удастся извернуться допрасходы уронить текущим числом... |
|||
42
Злопчинский
11.04.12
✎
00:00
|
(39) сервер/комп?
|
|||
43
shag008
11.04.12
✎
00:01
|
(42) на сервере
|
|||
44
Злопчинский
11.04.12
✎
00:04
|
(43) понял, с текучкой разгребусь - попробую.
. в УРБД я ноль практически - поможешь по елочи? |
|||
45
shag008
11.04.12
✎
00:04
|
(42) причем, как я уже писал, если в периферийке данных никаких не менять, то обратная выгрузка - секунда-две
там только подтверждение о загруженных данных |
|||
46
йцукецоп
11.04.12
✎
00:04
|
(41)см 23
|
|||
47
Злопчинский
11.04.12
✎
00:07
|
(46) нуну.. япосмотрю как ты откажешься от исправленяи документа задним числом месячной давнойти когда из сетевого магазин откуданить из волгограда или другого мухосранска приедт дебет =-нота с требованием предоставить исправленные документы (не корректировочные). и все. и апож. с сетками особо не пободаешься. хоть обуправляйся. но - боремся! ;-)
|
|||
48
shag008
11.04.12
✎
00:07
|
(44) без проблем
для автоматизации этого процесса есть замечательная и недорогая программка УРБД-мастер ищется в любом поисковике плюс всей этой системы в том, что в случае вылета основной базы всё легко разворачивается из почти актуальной периферийной базы за каких-то полчаса |
|||
49
Злопчинский
11.04.12
✎
00:08
|
(48) угумс, спсб!
|
|||
50
Злопчинский
11.04.12
✎
00:09
|
ладно, всем спсб! пошел упаду в ванну книжку дочитаю страниц 200
|
|||
51
shag008
11.04.12
✎
00:09
|
(49) мыло в профиле есть
если что-пиши, спрашивай |
|||
52
йцукецоп
11.04.12
✎
00:18
|
(47) да норм все ) приходят такие тр)
|
|||
53
jsmith
11.04.12
✎
00:23
|
3 Гб, больше не довелось, ибо работаю только с восьмёркой
|
|||
54
shag008
11.04.12
✎
00:26
|
(0) 7 Гб вся база
Самый большой файл - 1,3 Гб Используется kernel33 |
|||
55
Aleksey
11.04.12
✎
00:30
|
(19) Случай из практики. Принесли служебку, мол накосячили в приходе, не те цены поставили, нужно исправить. Ок, исправляем. Через полчаса после исправления. Новая служебка ... вообщем цены там были правильные и не нужно исправлять.... верните все обратно. Так что идеотизм отдельных личностей не знает границ
|
|||
56
Злой Бобр
11.04.12
✎
00:51
|
(37) Исходя из того что ГБ всегда прав могу только посоветовать вашему ГБ посмотреть в сторону банковского учета. Там нет такого понятия как вчерашний день, не говоря о месяце как у вас. Там все сидят до упору пока незакроют текущий день. У вас же ГБ явно булки расслабил, при попустительстве директора, которому либо глубоко на все ***, либо жаба душит денег заплатить другим ГБ за консультацию. В общем нормально себестоимость выводится уже после продажи товара, неважно частичной или полной. И даже корректируется текущим периодом прошлые периоды. И ничего военного тут нету.
Так что про специфику ненужно тут ля-ля. Знаем, плавали. На скуль переводят базы в первую очередь что б не заниматься ритуалом обрезания, а иметь возможность в одной базе посмотреть прошлые периоды и сравнить динамику и пр. Плюс, как уже говорилось, возможность бекапов, реиндексаций, ... средсвами скуля. Насчет замедления работы. Да, отчеты которые в дбф выплевывали данные, тут будут вызывать недоумение а иногда и панику. При переписи на прямые запросы когда возьмете большой период, то скуль выплюнет результат быстрее. Ну и т.д. При все плюсах и минусах переход на скуль все же более плюсовой. Единственное неэкономить на железе и изначально его правильно настроить. И неберите большие диски, 8х150 GB для работы и терабайтник для файлопомойки вполне хватит. |
|||
57
Torquader
11.04.12
✎
01:40
|
Вопрос такой -а насколько важно,чтобы главбух работал в оперативной базе -не проще ли сделать копиюи ему персонально выгружать всё,что нужно из рабочей,а в рабочей просто расстаться с бух-итогами,так как они съедают место и время.
|
|||
58
romix
11.04.12
✎
01:40
|
(0) По хорошему там надо все ЕДРО переписывать, чтобы не было ограничений на 2 гига и известных ошибок (фирма-разработчик ядра кстати так и сделала). Hogik прикрутил другие движки и исправил ряд известных ошибок патчами. Я не очень представляю зачем файл-серверные движки нужны были вообще, разве что как наследие MS-DOS.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |