| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Foxpro/Clipper/Dbase > Сравнение двух таблиц |
| Автор: Татка 6.6.2012, 15:24 |
| Здравствуйте. Есть две таблицы: Spravochnik.dbf и itog.dbf . Обе таблицы содержат реквизит номер цеха nz. Необходимо сравнить эти две таблицы по реквизиту "номер цеха" (nz) и в случае совпадения заменить реквизит код производства (kpr) массива Spravochnik.dbf реквизитом код производства (kpr) массива itog.dbf. Подскажите, пожалуйста, как это можно сделать? |
| Автор: Данкинг 6.6.2012, 15:30 | ||
|
| Автор: Reese 7.6.2012, 15:01 | ||
Relation давно уж надо на помойку выбросить
Можно update и по таблице сделать, но толь я не знаю как готовить, то ли он действительно такой медленный |
| Автор: Данкинг 7.6.2012, 15:10 | ||
Хм. А апдейтить Spravochnik столько раз, сколько строк в ITOG - это, конечно, лучше?  Добавлено через 4 минуты и 1 секунду Да и зачем писать программу, если связь на уровне СУБД устанавливается, т.е. её средствами? |
| Автор: Reese 7.6.2012, 15:52 | ||
Сколько найдет. Если таких записей в Spravochnik нет, то и апдейтиться ничего не будет. Плюс моего решения - не зависит от индекса Фокс до сих пор поддерживает @say, но это не значит что этим нужно пользоваться |
| Автор: Данкинг 7.6.2012, 20:17 | ||
Но каждый раз будет проходит все записи целиком. Смысл? |
| Автор: Reese 8.6.2012, 09:53 | ||||
Такой же как и в
В вашем случае тоже обрабатываются все записи. Просто update понятнее т.к. такой код читать легче чем искать где и как устанавливали relation, и безопаснее, т.к. в случае сломанного индекса ваш пример во всей таблице Spravochnik поставит в поле kpr одно значение, а в моем - просто отработает медленнее. |
| Автор: Данкинг 8.6.2012, 11:10 | ||||
Не знаю именно самого механизма работы - может быть, там используется какой-то свой внутренний UPDATE. Я про то, что при связывании я делаю всё одной командой - REPLACE - и жду, пока она отработает. Да и в любом случае - зачем писать программу, если можно сделать одной строкой? Добавлено через 43 секунды
Какого сломанного: я в подобных случаях обычно заново переиндексирую. |
| Автор: Reese 8.6.2012, 13:07 | ||||
Какой же одной ? В одну строчку разница.
А если индекс сломался во время работы replace for ? |
| Автор: Данкинг 8.6.2012, 13:20 | ||||
Нет, это просто я написал, как это сделать программно. Но самом фоксе же есть построитель выражений, в том числе и для установки связей. Я всегда его и использую.
Это с чего вдруг? Вот ни разу подобного не было. |
| Автор: Reese 8.6.2012, 14:56 | ||||
1. Этот построитель дал вам тот-же код 2. Использование визардов - зло
При сетевой работе (особенно если программа написана через всякие relation) - слетают регулярно. (Особенно если некоторые пользователи вместо кнопки отмена выдергивают вилку компа) |
| Автор: Данкинг 8.6.2012, 17:29 | ||||||
Правильно, но я же PRG не писал.
Как правило - да, но не всегда и не везде.
При чём здесь это? А что будет, если прилетят зелёные человечки и унесут системник? |
| Автор: Reese 9.6.2012, 09:24 |
| Про выдергивание вилки я конечно несколько утрировал, но я часто встречался с тем что пользователи сбрасывают задачу или жмут reset когда уже нажали "сохранить" и вспомнили что-что-то забыли. |
| Автор: Данкинг 9.6.2012, 11:33 | ||
Да при этом вообще таблица не сохранится, что бы с ней ни делали. Именно RELATION или индексы тут ни при чём. |
| Автор: Reese 9.6.2012, 13:01 | ||
Причем тут сохранение таблицы? Таблица уже есть. В нее записывают данные при помощи уже написанной программы, а написан процесс сохранения какого нибудь документа при помощи relation, append blank, и replace. База лежит на сетевом диске, работают два пользователя, и один из них сбрасывает задачу в момент записи данных. Вот тут обычно и происходит слом индексов. (обычно при попытке искать по такому индексу всегда возвращается первая запись). |
| Автор: Данкинг 9.6.2012, 14:10 | ||||
В смысле, если открыть таблицу, записать что-нибудь в поле и снять задачу VFP, то записанные данные не сохранятся.
В сетевом режиме на фоксе лучше уже вообще не работать, он всё же не для этого. |
| Автор: Reese 9.6.2012, 14:34 | ||||
Конечно. В этом случае сохранение происходит только после ухода с поля. Т.к. в момент ручного редактирования мы работаем с буфером. (Не помню, можно ли его отключить) Но в любом случае это не называется работой с БД
Он именно для этого и разрабатывался. |
| Автор: Данкинг 9.6.2012, 16:34 | ||||
Нет. Сохранение происходит или при закрытии (нормальном) фокса, или же принудительно командой FLUSH.
Может быть, когда альтернативы не было. Но сейчас я не представляю сетевую работу с фоксовой таблицей в 13 миллионов записей (какая вот у меня есть на FireBird). |
| Автор: Reese 9.6.2012, 17:47 | ||||
Да. тут я не совсем прав. Если быть точным, то сохранение происходит в зависимости от типа буферизации. Не помню сейчас как они точно называются, но в двух случаях запись происходит при смене строки (тут я тоже не совсем точен насчет поля). Но это что касается работы с таблицей вручную, а так с таблицами все таки не работают. Только если что поправить надо.
Он и сейчас занимает свою нишу. Но сепецов по нему все меньше и меньше, да и Microsoft не хочет его развивать. Не выгоден он им. Да. 13 миллионов будет уже тяжеловато для фокса. Но на 10-20 рабочих мест при размере таблиц в пределах 10 миллионов с сумарным весом БД в пределах 2 гб - фокс чуствует себя совсем не плохо. Опять же вместо сервера можно поставить простенький NAS (главное чтоб SMB нормально поддерживал и блокировки работали) и в случае какой нибудь поломки можно и по телефону объяснить что и куда скопировать т.к. уж чего-чего а с файлами всякие тетушки обычно справляются. Если что-то крупнее, то я тоже предпочту FireBird или DB2 (благо бесплатная версия не имеет ограничений на размер БД) к ним можно из того же Фокса подключиться. |
| Автор: Данкинг 9.6.2012, 19:15 | ||||||
А где она меняется?
Работают-работают. 
Это если там одно поле только. Ну или два. |
| Автор: Reese 9.6.2012, 22:01 | ||||||
свойство BufferMode у объектов _screen и form
15 полей. объем таблицы - чуть меньше 1 Гб
А смысл. Для такой работы обычно табличные процессоры используют. |
| Автор: Данкинг 9.6.2012, 22:13 | ||||||
А в меню фокса нет такой опции?
Ну, значит, поля по размеру небольшие.
Какие ещё процессоры: открыл таблицу в фоксе - и вперёд. Кстати, попробовал связку и UPDATE - связка в разы быстрее работает, как я и говорил. |
| Автор: Reese 10.6.2012, 11:06 | ||||||||
В в среднем C(50)
Нет. А зачем она там ?
Excel, Calc и т.д.
А поля, по которым идет поиск, проиндексировали ? Ну не может оно в разы быть медленнее |
| Автор: Данкинг 10.6.2012, 11:28 | ||||||
Только просматривать и редактировать таблицу в фоксе куда удобнее, чем в Excel, который к тому же только 65 с чем-то там тысяч записей поддерживает. В Calc с версии ОО 3.3 поддерживается и больше, но при этом файл на 300000 записей открывается час, т.е. скорость у ОО оставляет желать лучшего.
А, забыл.  Прога на работе, тогда после выходных гляну.
Ну вот, смотря что хранить в такой таблице. |
| Автор: Данкинг 17.6.2012, 21:21 | ||
Глянул, кстати. UPDATE с индексированным полем аналогично долго работает. |
| Автор: Reese 18.6.2012, 09:56 | ||
Ну быть такого не может. Можете скинуть код с описанием полей и индексов? |
| Автор: Данкинг 18.6.2012, 10:21 | ||
Ну, суть в том, что вторая таблица индексируется по полю (пусть будет INDEXPOLE), далее идёт цикл по первой таблице и запрос типа такого:
|
| Автор: Reese 18.6.2012, 11:38 |
| так я же писал что update по таблице действительно медленный SCAN + update - тогда быстро И еще, какой уровень оптимизации? Что-то я не уверен что в вашем случае UPDATE будет использовать индекс. |
| Автор: Данкинг 18.6.2012, 13:24 |
| А при чём здесь scan ? Какая разница, откуда я получаю значение? |
| Автор: Reese 18.6.2012, 15:05 |
| При том что join на update-е у фокса медленный. Поэтому Join эмулируем через select ... into cursor и scan c update-ом. Увы, но это то ли просто особенность фоксового SQL-движка, то ли, вообще, баг. |
| Автор: klepus 14.10.2012, 14:31 |
| Привет, у меня похожий вопрос, но у меня не получается... Есть 2 таблицы (табл1, табл2). Таблица 1 - это курсор в котором всего 2 столбца. Таблица 2 - это 2 этих же столбца + ещё 2 других. Одинаковые столбцы z2 C(8), z3 N(8) Мне надо, чтобы при удаление/добавление/редактирование, записей в этих столбцах первой таблицы, тоже самое происходило во второй (Обратное не надо). Но остальные столбцы второй таблицы должны остаться без изменения. Если всё совпадает, то ничего не делать. Вообщем, что бы таблица 2 реагировала на изменение в таблице 1 в общих столбцах, но она не должна терять информацию, которая содержится в других столбцах. |
| Автор: Данкинг 14.10.2012, 14:38 | ||
Это каким образом осуществляется? |
| Автор: klepus 14.10.2012, 14:44 | ||||
Ну первая таблица, редактируется кем то периодически, не зависимо от меня. То удалят строку, то добавят новую. А моя (вторая таблица) должна всё это отражать в себе. |
| Автор: Данкинг 14.10.2012, 17:27 | ||
Удаление осуществляется программно или вручную? |
| Автор: klepus 14.10.2012, 18:12 | ||||
Вручную. |
| Автор: Данкинг 14.10.2012, 20:56 |
| Тогда никак: триггеров на фоксе ещё не придумали. |
| Автор: Reese 18.10.2012, 11:43 |
| Можно просто по таймеру проверять изменения. Если таблица лежит в контейнере, то можно и триггер (вообще то они в фоксе есть). |
| Автор: Данкинг 18.10.2012, 12:08 | ||
Где они есть: небось только в 9-м фоксе и только для таблиц в составе БД? |
| Автор: Reese 19.10.2012, 10:59 |
| В 6-ом точно были. Но как я уже говорил, только для таблиц в контейнере БД. |
