Вита на добро пробило?

Да я тут эта... лапой зажал, держу из последних сил чтоб не прорвало.

_vit
И это хорошо а ведь могли бы сказать добавляй новую программу на новый период...

На новом периоде выставляются все остатки, изменения в структуре, ...
В зарплате 3 года по-любому хранить надо. Еще есть "оперативные" копии, кот. юзер без всякого сисадмина пользуется.
В других проектах по-разному. Грохнуть старые таблицы даже сисадмин может без нашей программы.

А еще протоколы - кто когда и что исправлял, удалял. Такое даже в 1С есть.
Тут в Решениях моя "a la Excel", у нас это, где задано, работает и между сеансами.

Прорвет - не страшно!



Исправлено 1 раз(а). Последнее : Ydin, 02.01.18 22:40

Пробивайся, Вит, чё ждать?

of63
Пробивайся, Вит, чё ждать?

В БВ фин. деятельность структуры (3 уровня) предприятий, их 130 примерно.
Структура меняется, кого-то объединили, кого-то убрали, кого-то переподчинили.
С начала года начали как с нуля. Остатки, типа нулевой месяц, посчитали, юзер вручную их покорректировал, утвердил и - вперед.
За прошлый год могут смотреть как оно и было. С нового - с учетом этих остатков, а не из таблиц прошлых лет.
Разные отчетные формы, плановые формы меняются не по-мелкому.

Цитата:

И это хорошо а ведь могли бы сказать добавляй новую программу на новый период...

И это тоже. Бизнес-логика вынесена и зависит от периода. Но только там, где надо.



Исправлено 1 раз(а). Последнее : Ydin, 02.01.18 23:13

Александр, подобную тематику и "программирую". Ничего в это особенного, кроме ка к"ЭТО ДОЛЖНО РАБОТАТЬ" и нет. И это... "прикольно", потому что это зависит от тебя... правда, после 10-20 лет зависимости, ... уже не поймешь, кто от кого зависит... )

Вообще, не верю в универсальность просто данных в БД только со всякими обычными данными.
Еще должны быть коды программные в мемо-полях, кот. работают по ExecScript.
Поэтому мне нравится Фокс, где это реализовать легко!
2 of63 - да!



Исправлено 1 раз(а). Последнее : Ydin, 02.01.18 23:21

Ydin
или не было выбора - сделать правильно или опоздать на поезд в пятницу.

Ну как исключение вариант переноса из FPD/Clipper я таки указал. Да, это "оправдывает". Но писать НОВЫЙ проект с таким подходом - не вижу разумных причин.

Ydin
Вообще, не делаю БД! Делаю какой-то софт. И, если вдруг, сказали надо добавлять таблицы на новый период...

Не, ну если ты таки чисто кодер, а вопросы архитектуры (в т.ч. и это - делать 100500 таблиц на пустом месте) решает за тебя некто другой - ну значит ему и переадресуй моё фи
Если что, я точно такое же г* видел и в тех же оракловских базах. Ну не умеет человек, не понимает как так - держать и январь и февраль, и, о боже, март с апрелем в одной таблице Ведь на печати это же были совершенно отдельные кипы бумаги

Ydin

Цитата:

Резервная копия, вообще-то, должна включать в себя ВСЕ компоненты БД

Чего это вдруг?
У нас разные.
В одной моей реализации они 3-х видов с разной периодичностью:

Для возможности восстановления - даже в том случае если "всё сгорело дотла".
Естественно восстановление должно быть корректным - т.е. данные должны быть непротиворечивы и "полны" на момент создания резервной копии. Если ты восстановишь таблицу "расхода" но не восстановишь таблицу "прихода" - это будет катастрофа.
Описанная тобой схема, конечно же, имеет право на жизнь - только она:
- весьма сложна - даже сложнее того что я писал выше про "чистую БД" и "только данные".
- по сути резервной копией является НАБОР архивов, начиная с "полного". Т.е. где-то там "в цепочке" рано или поздно встретится и архив с dbc - и проблем "всё восстановить" не будет. Даже если по твоей схеме делать инкрементальные архивы.
Если что, в том же оракле система резервного копирования тоже позволяет делать "инкрементальные" бэкапы - НО в основе всегда лежит один "полный" - на него потом (в случае восстановления, в т.ч. и не при сбое, а при особо серьёзных "косяках" персонала - когда просто нужно "вернуться во вчера") накатываются сравнительно мелкие "инкрементальные" копии. Конечно же в любом случае БД восстанавливается до некоторого согласованного состояния - восстановить БД (по крайней мере штатным образом) так, чтобы половина таблиц была по "состоянию на вчера", а вторая половина по состоянию "на начало 1990 года" нельзя. Тут разработчики СУБД сделали таки заборчик от "обычных" идиотов, конечно, от особо упоротых это не поможет, впрочем, таковые, как правило, и не делают никаких резервных копий

_vit
а ведь могли бы сказать добавляй новую программу на новый период

А ты никогда не видел на рабочем столе узера кучу иконок типа "программа на январь 2018 года" И это вовсе не ссылки на экселевские документы
Ладно кое кто в программу вставляет функцию по "созданию набора таблиц на каждый отчётный период", а есть же гении которые такую функцию не вставляют, а "таблички" то у них именно на один отчётный период и рассчитаны Ничего, добрый одмин сделает xcopy и заведёт новый ярлычок...

Справедливости ради - иногда такой подход оправдывает себя. Если "логика" этих самых расчётов таки меняется ежемесячно. Чем делать (постоянно наращивая) километровый CASE, проще каждый месяц просто менять код, и делать "новую копию". Конечно же ни про какие "сводные" отчёты, речи идти уже не может...
Не удивлюсь, если в волшебной сфере ЖКХ это как раз "типичная ситуация"

Igor Korolyov
А ты никогда не видел на рабочем столе узера кучу иконок типа "программа на январь 2018 года" И это вовсе не ссылки на экселевские документы
Ладно кое кто в программу вставляет функцию по "созданию набора таблиц на каждый отчётный период", а есть же гении которые такую функцию не вставляют, а "таблички" то у них именно на один отчётный период и рассчитаны Ничего, добрый одмин сделает xcopy и заведёт новый ярлычок...

Справедливости ради - иногда такой подход оправдывает себя. Если "логика" этих самых расчётов таки меняется ежемесячно. Чем делать (постоянно наращивая) километровый CASE, проще каждый месяц просто менять код, и делать "новую копию". Конечно же ни про какие "сводные" отчёты, речи идти уже не может...
Не удивлюсь, если в волшебной сфере ЖКХ это как раз "типичная ситуация"

Работала в Казстате (агентство по статистике), там именно такая ситуация и была. Каждый квартал менялась логика формирования квартальных отчётов и приходилось на каждый квартал делать свою "программу" и у юзера копились ярлычки - "кв.1-2-3-4". Гос.органы почему то грешат частой сменой логики формирования отчётности. Не успеваешь уследить изменения. Там видимо сидит целая орава "дармоедов" и только и делают, что подкидывают работу нормальным людям.

Ydin

Цитата:

Вообще-то, довольно много. Это "в принципе" другой способ работы с данными.

Есть что-то хорошее для "совсем новичка", условно. Ему - это способ для "научиться ходить на своих ногах в Фоксе".
Ну, я считаю, что этот уровень прошел (IMHO).
Для меня "dbc контейнер" - это типа Formset, здесь типа неудачная попытка "косить" под Ораклы.
И это, IMHO, надо просто похоронить, если уже попробовал на серьезном.
Там на 2 пальца удобств, и на 1 палец неудобств. Но это разные пальцы.

База данных как идея - это комплекс взаимосвязанных между собой объектов. Т.е. изменение в одном объекте оказывает влияние на другой объект.

Эту взаимосвязь можно реализовать "вручную". Программированием. Что и делают при работе со свободными таблицами

Но можно до некоторой степени автоматизировать. Подобную автоматизацию и позволяет реализовать "база данных" как контейнер DBC в FoxPro или "большие" СУБД вроде MS SQL, Oracle. Т.е. это некое взаимодействие объектов внутри базы данных, не зависящее от приложения, которое с этими данными работает. Так сказать, приложение в приложении.

Естественно, если ты привык управлять данными "вручную", то "передать управление" какому-то "левому" приложению сложно. Чисто психологически. Всегда найдутся 100500 причин этого не делать. Как следствие, используют базы данных как некую "папку" в проводнике. Просто место хранения. "Выхолащивая" саму идею концепции "базы данных"

Еще раз. Работа с базой данных - это принципиально другой стиль написания приложений. Это другая идея, концепция, построения приложений. Повторю сравнение - это как писать монопольное и многопользовательское приложение. Внешне, вроде, похоже, но внутренне - это разные вещи

Конкретная техническая реализация базы данных (контейнер DBC) - вторична. Здесь важна сама идея частичной передачи управления другому "приложению". Именно с этим связаны разные как чисто технические, так и психологические особенности перехода на работу с базой данных

Божья_коровка
Гос.органы почему то грешат частой сменой логики формирования отчётности.

В этом нет ничего удивительного. У госорганов есть два "бога" - численность работников госоргана и бюджет. Этих два показателя всегда или почти всегда завязаны на статотчетность, получаемую от подведомственных предприятий. Как только статистика начинает угрожать финансам или численности, ее меняют. Просто - как мычание.

Не проще ли менять сводную отчетность в самом гос.органе по сравнению с входящей первичной отчетностью от подведомственных предприятий.

spinz
Не проще ли менять сводную отчетность в самом гос.органе по сравнению с входящей первичной отчетностью от подведомственных предприятий.

Был у нас случай на предприятии - попросили устроить очень нужного человека на полставки с окладом 4.5 млн рублей (это на полставки уже). После первой же подачи П1 нам со слезами звонили из росстата, просили не портить статистику. Там весь ФОТ был 45 без учёта социальных выплат.

spinz
Не проще ли менять сводную отчетность в самом гос.органе по сравнению с входящей первичной отчетностью от подведомственных предприятий.

Что за крамольные мысли? Этак ты ещё дойдёшь и до того что надо бы 90% чиновников на...улицу выставить, т.к. они ровным счётом ничего полезного не делают
Всё запутывать и усложнять жизнь другим - основная работа бюрократического аппарата.

Есть добротный английский сериал "Да, господин министр!" и продолжение "Да, господин премьер-министр!" Там демонстрируются вершины административного мастерства в английском правительстве. Желающие могут основательно "подковаться", посмотрев сериалы.



Исправлено 1 раз(а). Последнее : Simple777, 03.01.18 18:58

Цитата:

Перед использованием таблицы можно сделать ее копию, по окончании использования (или во время) - сравнить с копией (тривиальная програмка), не пристраивая никакие настоящие БД-шные "механизмы"...

поэтому размер dbf ограничили двумя гигабайтами