вносились в таблицю, де ід запису генерилось як автоінкремент.
Показав одному толковому працівнику як правити напряму в базі.
Через якийсь час власник звернувся, що в нього чомусь часто почала не сходитись виручка.
Згенерував послідовність ід в окрему таблицю, порівняв з існуючою. Побачив, що декілька записів були видалені (не вистачало ід).
Так виявив кражідку. Якби він трошки подумав, то просто би правив суми, а не видаляв записи повністю.
Потім виникло питання вже з ід. Бо розвернули базу в іншому регіоні. Там почали працювати з чистою базою Ну і ід в одному підрозділі співпадало з іншим підрозділом.
Коли виникло питання злити все в одну базу, то зрозумів що треба було все ж використати GUID. Викрутився додатковим полем, не подумав коли створював базу.
Дві класики :)
Ну, поався :) Тепер вже розставляю на це пастки. Типу записую суми в окрему таблицю з дивними назвами полів. Аби не здогадались. В прикрих ситуаціях просто звіряюсь. Або ігнорує рекомендації надлишковості полів. Наприклад в таблицю накладні записую також і суму, хоча її можна вирахувати із складових накладних (позицій)
Із накладними це гарне рішення. Це так саме люди бачать ці речі, і так саме крадіжки у теплі ловляться
Трохи погане, бо складові редагують і тоді треба вже думати чи це так має бути чи махінації. Найкраще все ж таблиця історії (типу логи дій користувачів). Типу було і стало
винайшли подвійний запис з класичної бухгалтерії :)
Обсуждают сегодня