Итак, имеем ситуацию, когда бухгалтеру приходится быть также системотехником (разработчиком).
Если "не запускается" или "не видит", то да, это к системному адинистратору или ИТ-специалисту с их кубернетесами и пробросами портов:). Мы-то с вами знаем, что главная головоломка в самой задаче учёта, дай-то бог хоть как-то решить именно ЕЁ, а "системные" вопросы... "Марья Ивановна, мне бы ваши проблемы" (анекдот про Вовочку).
То ли нарвались на неадекват готовой программы. То ли нужно выдать новый документ, которого раньше не выдавали. То ли вы и есть в натуре разработчик, и знаете, что новые требования к программе неминуемо возникнут, но какие именно - это находится на грани нормального предвидения :). А надо предвидеть, иначе потом половину будете перепрограммировать заново.
Проблемы здесь в области логической схемы базы данных ещё ДО всяких других проблем.
Но некоторые из этих "других" более, так сказать, возвышенных проблем системотехнику знать надо.
Допустим, с логической схемой базы данных разобрались!
Данные по таблицам - распределили!
Или мы сами их распределяем, или расшифровали, что же где и как эта программа хранит и как туда доступиться.
То есть доставать из базы нужные данные мы теперь можем, и даже ненужные с заделом на будущее.
А как насчёт того, чтобы оно не развалилось на ходу.
Оно-то правильное, но а вдруг нестойкое.
Как это может быть?
Вернёмся к примеру с накладной, в которой содержится список товаров.
Как мы запроектировали, сама накладная пишется в одну таблицу, товары в другую.
Более "бухгалтерский" вариант такой: поступает документ, на основании которого делается несколько проводок. Документ пишется в базу документов, проводки - в общий файл (таблицу) проводок. Про файл проводок мы говорили, пример дикой работы с таким документом приводили - клерк вводит чек в окно пр-ммы работы с этими чеками, и тут же в соседнем окне 1С бухгалтерии вручную рождает соотнесенные проводки. Это потому, что хотя в 1С нормальная возможность делать проводки по документу и есть, но вот этот чек не запрограммировали :(
Дикое оно или не дикое, документ раскидывается сразу по нескольким местам базы.
Допустим, сначала пишем товары с накладной, потом саму накладную.
Половину товаров записали, произошёл сбой. И в файле товаров теперь "висят" товары неизвестно откуда.
В принципе, известно (при записи о товарах есть номер накладной, которой, выходит, в базе нет). Но это ещё надо проверять.
Или - проводки записаны, сам документ не записан. Без проверки собираем свод, а в нём лишние непонятно откуда взявшиеся проводки и суммы.
Или, хуже того, после сбоя вводим документ повторно, а система генерации уникальных кодов документов назначает документу тот же номер (в прошлый раз она не успела отметить, что он уже использован), и на документе теперь некоторые проводки по два раза (или в накладной дублирующие строки с товарами: одна с недовведенного с прошлого раза, другая с успешно повторно введённого). И это не будет выявлено простым контролем целостности базы. Как мы там уже решили, одинаковые товары в разных строках - разрешены.
Этот ужас - с натуры :)
Чтобы такого не было, из головы придумали механизм ТРАНЗАКЦИЙ. Уж извините, что не написал короче: транзакции, а разжёвываю. Вопрос тонкий и... чёрт бы его драл, практический.
Транзакция - это последовательность операций, которая ОБЯЗАТЕЛЬНО должна завершиться, притом полностью, а не частично. При этом с теми данными, с которыми работает транзакция, никто работать не имеет права, пока она не закончила. Это на случай, если с другого терминала пишут про те же обьекты, или кто-то с другого терминала вот прямо сейчас запросил отчёт (по ещё недовведенным данным). При этом если транзакция оборвалась (зависло на середине ввода документа), то очень хорошо будет, если все следы недоделанной транзакции (мусор) можно удалить из базы данных, то есть произвести ОТКАТ к тому прежнему состоянию, которое было до сбоя.
Ну и где же здесь транзакция? (ужасный пример выше). ... да как-то можно, если этот номер попадает в сферу контроля "движка" базы данных...
Примеры подходов к организации транзакций.
1. В программе программистом явно указывается, в каком месте программы начинается транзакция, и в каком она заканчивается. При этом между началом и концом доступ к используемым программным обьектам блокируется автоматически без явного программирования блокировки.
2. Транзакция "собирается" как задание движку базы данных, и организуется ОЧЕРЕДЬ транзакций к исполнителю ("движку"), который конкретно пишет и читает базу данных. Это хорошо тем, что "недошедшие" до базы транзакции могут быть после восстановления выполнены из очереди, и документы (запросы) не нужно будет вводить повторно. Если бы ещё об этом и выдавалось сообщение:)
.... ужасы, ужасы... Заплатили за билет на самолёт, оно зависло, и не понять, оно таки заплатило или нет :))))))))
И даже деньги со счёта ушли, а туда они дошли, или нет.
И если дошли, и билет через час в браузер пришёл, а место в самолёте забито, или нет?!
Появилось новое понятие: ДВИЖОК базы данных. Название это жаргонное.
Начиная с какого-то времени, разработчики программ стали отделять алгоритм расчёта от непосредственной работы с хранилищем данных.
(Стали как бы хотеть его отделять:)
То есть под одну и ту же готовую компьютерную бухгалтерию (вроде 1С или Паруса) стало возможным "подвести" разные системы управления данными (например, SQL-сервера).
Задание: уточните, в вашей программе оно есть, или нет.
Если движок отделён, то это даёт большое дополнительное удобство.
"Движки" имеют свои, независимые от самопальных программ, средства просмотра логической схемы базы данных, свои средства выборки данных (запросов), свои средства манипулирования данными (можно менять данные независимо от "программы", которая вдруг уже вообще ничего не может), свои средства конвертации данных в формат других программ... можно навесить сверху свою программу ...много чего, и проблем из 2-го абзаца главы меньше.
Например, если вы имеете доступ к SQL, то можете, "попыхтев", таки сделать дикую выходную форму, которая неожиданно свалилась вам на голову, и которой в 1С готовой нет.
Но с вероятностью в 50% для вас это утопия.
(вы выполнили задание?:)
У вас может оказаться либо старая версия 1С с жёстко зашитым внутри PRG DBF, либо вообще какое-то аморфное и бестолковое чудовище без всякой ни логической, ни физической схемы базы данных, и с файлами базы непонятно какого самопального же формата. Либо те же транзакции обещаны вместе с расфуфыренным фасадом движка, но по факту непригодны.
Допустим, вы попадаете в другие, хорошие, 50%
Но и это еще не всё. Про обещанные тонкости далее.
Продолжение следует
