|
|
|
Проблема помогите!
|
|||
|---|---|---|---|
|
#18+
lo-pataМожно просто поставить в поле праймери индекса табдицы default=reccount() и после аппенда делать replace sklad with 'склад'+alltr(str(id)). Тогда точно не будет совпадающих номеров складов Но тут уж такой прикол получится: если есть 3 склада и удалишь второй, то потом склад2 уже не создашь - только склад4. И будет тебе счастье... До первого PACK'а ;-))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2005, 23:33:43 |
|
||
|
Проблема помогите!
|
|||
|---|---|---|---|
|
#18+
Hi Urri! Да, NewID. А Sequence в Oracle - это идеологический родственник NewID :) 2 lo-pata Делаем PACK и ... отправляем твой способ в сад :) Кроме того при работе с представлениями это опять таки вызовет совсем ненужные проблемы... Чего мудрить то - NewID уже много лет существует и доказал свою надёжность - так ведь нет, надо поизобретать всякий ерунды - от SYS(2015) и прочих самопальных GUID-ов до CALCULATE MAX, RECCOUNT() - ещё бы RECNO() вспомнили :) Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2005, 02:26:02 |
|
||
|
Проблема помогите!
|
|||
|---|---|---|---|
|
#18+
NewID - не вопрос, но только для тех, кто работает с фоксом после семерки. Я обычно юзаю именно такой метод, какой я описал - именно реккаунт. Но!!!! всегда в программе делается пункт меню "сервис" - в котором есть и конфиг программы (пути к базам прописать) и всегда есть пункт (я так всегда делаю) - типа переиндексация базы или чистка, если хотите. Так там висит код, после которого и записи удаленные убираются и происходит ВСЕГДА проверка остающихся в базе данных. А там уже можно при проверке любые варианты рассмотреть - тут уж от задачи зависит, какие резы и данные, кот в дальнейшем вводиться будут. Так что реккоунт работает гут, но только при условии, что не программер местный каждый раз будет паки запускать и гробить всю нумерацию, а цивильно - юзер жмет пункт меню и выполняется чистка базы, переиндексация - да че угодно, но главное это в сервисах предусмотреть. Если такие вещи (типа переиндексации и пака) в меню предусмотреть - то вмешиваться в базу ручками и не надо будет. Единственное - пишешь инстракшен на листике и раздаешь юзерам, а лучше только юзерам с правами админов, и все. Они знают - раз в месяц надо запустить такой-то пункт меню и все будет супер гут, база будет почищена и раотать будет быстрее. Так что здесь проблем не метода, каким я пользуюсь, а именно сервсных функций, кот будут в программе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2005, 04:20:04 |
|
||
|
Проблема помогите!
|
|||
|---|---|---|---|
|
#18+
2lo-pata Вообще-то существует такая идеология проектирования баз данных, при которой delete отбрасывается напрочь, и все делается в основном через insert, ну а update остается только для того, чтобы помечать устаревшие записи как утратившие актуальность. Я даже нахожу такой подход очень привлекательным. Но практически он у меня применения не находит, так как всегда находятся ситуации, когда данные проще просто удалить, чем обеспечивать их версионность. Так, для справочника складов (который мы тут мусолим) удалить ненужный склад проще, чем объявить его закрытым для операций (ликвидированным), до тех пор, пока по этому складу не было ни одной складской проводки. Отсюда можно сделать вывод, что delete в реальной жизни встречаться будет. А описанный тобой подход несет в себе родовые травмы. Потому что если даже программа не предусматривает ни одного pack'а, ситуация, когда pack произойдет, рано или поздно случится. Вот уедут все админы и программеры ваши разом в отпуск - а база в это время упадет. Пригласят человека со стороны для восстановления. А он увидит, что туча удаленных записей в таблицах болтается - и какой будет его первая реакция? Пакануть, конечно. Смешно предполагать при этом, что он предварительно ознакомится с вашей инструкцией, в которой может быть даже 48-м кеглем написано, что этого делать нельзя ни в коем случае. Не тот человек и не та ситуация. А человек еще будет при этом над вами потешаться, что вы все - такие лохи, что даже базу не чистите, он так и не поймет, что такова была идеология ;-))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2005, 12:30:09 |
|
||
|
Проблема помогите!
|
|||
|---|---|---|---|
|
#18+
2 Urri Да все такой метод предусматривает - пакуй и удаляй на здоровье. Только я еще раз говорю - не ручками через фокс, а напиши сервисную функцию в проге. Привожу пример: есть таблица "справочник материалов", есть вторая таблица "сметы". Метериалы: mat_id mat_name 1 цемент м400 2 цемент м500 3 кирпич Сметы: smet_id smet_name mat_id 1 смета1 1 1 смета1 2 1 смета1 3 2 смета2 1 2 смета2 2 Удаляем цемент м500. перепаковали базу, после пака пробежали по табличке и последовательно перенумеровали коды: mat_id mat_name 1 цемент м400 2 кирпич Теперь если дефолт в материалах стоит reccount()+1, то будет снова добавляться материал с кодом 3. Так вот: после пака материалов нужно просто еще пробежать по таблице сметы, удалить все материалы с кодом 2 и там где материалы с кодом 3 - заменить его на 2. Все - работать будет великолепно. А основание делать паки и переиндексации программно есть, причем очень веское! Если ты написал прогу для своей компании и она только у вас активно используется - то можно и ручками перепаковывать. А если ты ее сделал на заказ и она используется где-то далеко компанией, в кот и программеров-то нет? Кто там и что ручками будет через фокс делать? А перепаковывать и переиндексировать базу время от времени надо. И че делать-то? Они тебе по почте будут несколькогигабайтную базу слать? Не выход. А если есть сервисная функция такая - то даже распоследний юзер (секретарша шефа ) сможет нажать кнопочку "переиндексация", если у него будет в инструкции это написано. ЗЫМ насчет примера - никто конечно же со сметами так не работает Если в ней был цемент, то он и должен остаться, а не на песок заменяться или удаляться вообще, так что не судите строго Это просто первый пример, кот пришел в голову. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2005, 14:26:01 |
|
||
|
Проблема помогите!
|
|||
|---|---|---|---|
|
#18+
2lo-pata А, теперь понял устройство несколько больше. Нет, все равно не одобряю. Слишком много накладных расходов, таких, как ресурсов, затрачиваемых на перепаковку, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2005, 14:56:02 |
|
||
|
Проблема помогите!
|
|||
|---|---|---|---|
|
#18+
Hi lo-pata! Это называется "... голова рукам покою не даёт" :) Т.е. дабы отстоять ВЕСЬМА спорное проектное решение (а не сделать нечто более нормальное и универсальное), приводится дикой код перекодирования :) Опять-же ты лишь на ОДИН момент ответил - про PACK - про работу НЕ напрямую с таблицей (а скажем с банальным представлением, особенно если надо СРАЗУ и основную запись вводить и подчинёные - для справочника складов это неактуально, а вот для всяких там накладных и прочего - очень даже нужно) - не ответил... Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2005, 03:15:49 |
|
||
|
Проблема помогите!
|
|||
|---|---|---|---|
|
#18+
2 Igor Korolyov А что там отвечать даже? Вообще не вижу проблемы - сделал себе представление, добавляй и удаляй что надо. Надо сохранить эти изменения в главной таблице и подчиненных? чем вопрос: никаких проблем нет. Делаешь аппенд в главную, в подчиненные - можно триггеры для таблиц прописать или в самом коде указать что и куда повставлять, где сложность? Удаление - то же самое. Может я и не прав, конечно, но приведи хоть пример, где могут вылезти партаки? Или воопрос сформулируй поконкретнее - отвечу более предметно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2005, 14:10:02 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=33160394&tid=1593878]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
194ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 227ms |
| total: | 519ms |

| 0 / 0 |
