Здравствуйте, Sinclair, Вы писали:

V>>И воровство при такой организации "учёта" обычно цветёт и пахнет, потому что достаточно поменять строчки заказа (цену в них или кол-во) и вся отчётность автоматом "плывёт". Разницу можно себе в карман. Наблюдал более 3-х раз вживую.
S>Это ортогональный вопрос. Возможность попатчить движения и остатки совершенно не зависит от того, сколько там участвует таблиц.

Зато безопасность зависит.
Когда у нас доступ к разным таблицам, то можно пользовать родную безопасноть серваков на основе ролей.
А когда речь о доступе к одной и той же, то безопасность тут обеспечивается лишь приложением, но всегда можно приконнектиться в обход приложения и поправить цифирки.

Да, это побочный эффект, но весьма забавный.
Несколько контор взяли мою систему в том числе потому что она позволяла защититься от воровства — достаточно было дать возможность проводить и отменять документы одному материально-ответственному лицу и усе.


V>>Отчет раз в месяц по read-only данным?
V>>После закрытия периода и подведения итогов?
S>Ежедневно в течение активного периода. После закрытия месяца уже поздно мотивировать менеджера.

Мотивирование — оно обычно деньгами, а "менеджеры" в торговых предприятиях — это просто девочки на выписке накладных.
Ну ОК, пусть активно, пусть даже каждый день хотя бы по разу для каждой девочки.
Такая "нагрузка" не стоит обсуждения, ИМХО.


V>>Кароч, есть несколько схем раздачи уникальных ключей и без механизма базы. Более того, почти всегда необходимо знать значение уникального суррогатного ключа еще до вставки. Это если мы всё еще об эффективности. Потому что в наколенных поделиях, разумеется, можно и узнать значение такого ключа уже после вставки, но я бы бил линейкой по пальцам, если бы речь шла о чём-то более-менее серьёзном.
S>И опять начинается некомпетентная чушь.

Да ладно, это чуть ли не норма — делать суррогатные ключи с автонумерацией.
Как раз в тех самых наколенных поделках цветёт и пахнет.


V>>Э-э-э. Вообще-то 3-я нормальная форма явно требует разрывать транзитивные замыкания, а не создавать их. ))
S>Так и любой индекс является денормализацией — по определению.

некомпетентная чушь (С)
Индекс согласован с данными "автоматически", прозрачно для тебя.
В этом сама суть ISAM-подхода (на который ты однажды накинулся, ХЗ зачем).
А избыточные данные юзверского уровня запросто могут находиться в несогласованном состоянии.


S>Он же вводит "вычисляемые" отношения в чистую реляционную модель.

В механику её реализации, а не в саму модель.
"Модель" — это то, что для человека, а не для машины. ))


S>Взрослые люди понимают, что бывают индексы, поддержанные на уровне СУБД, но они не исчерпывают все возможности по оптимизации. Поэтому может потребоваться вводить "рукопашные" индексы, теряя возможность автоматической оптимизации запросов.

Какое вольное обращение с терминологией.
Вики:

Индекс — объект базы данных, создаваемый с целью повышения производительности поиска данных.

S>Вот, хранение остатков — это один из вариантов такого индекса.

Остатки — это "регистры". Даже с учётом вольности терминологии, таки, есть принятое другое название в этой предметной области.
И то и другое индексами не является.

Индексы служат для быстрой навигации к нужным строкам БД.
Всё остальное — не индексы.

Твоё их понимание, заметь, уже не впишешь во "всего лишь широкое толкование".
Похоже, под индексами ты понимаешь эдакую "специальную копию/проекцию" самих данных или вычисляемых.
Но это всего лишь один из механизмов реализации индекса.
Индекс может быть вычисляемым, но при этом содержать данные, которых нет ни в одном оперируемом view.
Например, для хронологических данных индекс может содержать "склейку" периодов, а глупый программист и знать не будет, что у него нарисовалась вертикальная избыточность (тоже болезнь всех без исключения виденных наколенных поделок без отдельного механизма обслуживания периодических данных).

Кароч, пародируя твои же манеры порождения аргументов: хотя яблоки бывают красными, не всякое красное является яблоком.
))

S>Транзитивное замыкание — другой.

Если это не специальный объект базы, а просто данные в таблицах, т.е. это просто избыточность.


S>Нормализация базы нужна не сама по себе (иначе это — культ карго), а для достижения определённых целей.

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

В 5/6-й нормальных формах избыточные данные банально некуда писать.
Например, база Northwind не находится в 5-й нормальной форме хотя бы даже из-за поля ShipCity.


S>К сожалению, это мало кто понимает. Вот и возникают всякие идиотизмы типа раздельных полей для улицы/дома в адресе

Это идиотизм не потому что в БД есть запреты, а потому что бывают адреса без улицы, без домов и вообще в свободной форме.
Т.е. сама предметная область НЕ диктует такого разделения.

Хотя, в тех же госуслугах именно есть база домов и квартир, т.е. если согласно предметной области требуется именно такой учёт, то он
и реализуется, ес-но.


S>А под тем предлогом, что "ну это же правильное решение, которое всё равно мы будем делать рано или поздно" существующие отчёты по актуальным данным никто не развивает. Клиенты плачут и жалуются, а лично меня это бесит.
S>К сожалению, я слишком далёк от той части компании, которая занимается этим вопросом, и сделать ничего не могу.

Если есть мотив двигаться на конкретное рабочее место — то надо двигаться.


S>А вот до этого я работал в бодишопе, и к нам регулярно приходили заказы вроде "у нас есть учётная система, она прекрасно работает, кроме вот этих вот пяти мест — можете помочь?". И мы регулярно помогали. При этом без написания целой системы с нуля. Это зачастую вообще невозможно, потому что у мало-мальски развитой системы не существует покрывающей документации. В одну и ту же базу лазят клиенты на Дельфи, джавовский миддл-тиер, и тонна страничек на классическом ASP. А может и ещё что-нибудь, написанное в 1997 году контрактором и давно забытое.
S>Понять, кто зависит от структуры таблицы SurveyResponses — невозможно, т.к. нет даже способа получить все исходники зависимых систем.
S>Это означает, что мы принципиально не можем оценить стоимость проекта — может $100k, а может — $1m. "Как пойдёт".
S>Заказчики почему-то не согласны платить неизвестные заранее деньги и тратить неизвестное заранее время на решение, которое не имеет гарантированных преимуществ.
S>Поэтому они были очень рады, когда за $30k и две недели им чинили ровно эти пять мест, не ломая ничего из старого кода.

Мде. Если бы я за две недели чинил пять мест в SQL, я бы никогда ничего не написал бы.

Не, у нас ходили байки, что в больших городах у программистов скорость написания кода низкая (мы сравнивали — разница до 20-ти раз на проектах среднего уровня), просто я как-то упустил из виду, что к SQL это тоже относится. ))

Ребят, сорри, я вас иногда читаю — вы, блин, тепличные растения, жизни не нюхавшие.
Претензии на какой-то там "повышенный опыт", в сравнении с коллегами — ну они улыбают (это если цензурно).
Те задачи, которые решают настоящие боевые программисты, давай уж по-чеснаку, вы бы за эти задачи даже не взялись.
Только морщили бы носик и крутили у виска.
В лучшем случае выкатили бы в 10 раз больший бюджет и в 10 раз были бы больше требования к железу.
В нашей провинции с таким подходом просто не выживешь как программист в те года. ))

================
Ладно, всё это интересно, но уже давно не о том.
Ты хотел провести сам для себя сравнительный эксперимент схемы отдельными движениями — проведи.
Там не сложно.
Но для эфекта надо провести хотя бы на двух-трех типах складских документов, иначе эффект будет не заметен.

Еще ты хотел посмотреть на движки работы с таблицами напрямую?
Помимо InnoDB есть еще Btrive (как я мог запамятовать?)
Это тоже законченный ISAM-модуль, поверх которого работает движок PSQL.

И да, твои претензии к ISAM от непонимания, вестимо.
Тот же MS SQL — это банальный сервис над ISAM, т.е. непосредственный доступ к данным в данный момент времени имеет только одна программа.
В плане обсуждаемой системы "без SQL" это ни на что не влияет.