Есть ли какие-то соображения, кроме быстродействия?

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

"я как бы исхожу из того, что вот сейчас есть платформа 1С предлагающая разработчику и пользователю набор механизмов - "Регистры"."
Регистры - далеко не изобретение 1с. и даже не изобретение программистов.
Обычный инструмент. который применять не обязательно, но абсолютному большинству удобнее по неоднократно описаным причинам. Плюс за счет "предварительного просчета" увеличивается скорость получения итоговых данных, что тоже плюс. Но т.к. "предварительный расчет" тоже требует ресурсов, хранение предварительно расчитаных записей, и их итогов - тоже требует ресурсов, а кодирование требует работы (тоже ресурс) то "удобство инструмента" не "бесплатно". поэтому м ожно применять, а можно и не применять.

(805) это не является отклонением от нормальной формы.

(803) Под денормализацией в данном случае понимается наличие копии некоторых данных из таблицы в отдельном месте, именуемом индексом.

(808) следует ли понимать, что если я распечатал содержимое некоей базы, сущесвующей в нормальной форме - база денормализовалась? :-)

(808) Ага. Любая буферизация - это у нас кэш, а любая дупликация - это у нас денормализация. Что ж, понятненько.

(807) А кто-то где-то что-то писал про отклонения от нормальной формы? В общем-то было написано про наличие копий данных, которое обычно и именуется "денормализацией".

(811) а денормализация - это и есть отклонение от нормальной формы

(812) Отклонением от нормальной формы называют дублирование данных в таблице/отношении. Индекс не часть таблицы, хоть и очень с ней сильно связан, ибо является выборкой из неё.

(813) индекс является выборкой? :-) все чудесатее и чудесатее...

(809) Распечатка не часть базы. Будете дальше демагогические приемы испльзовать?

(813) заметьте, это всегда так: если ляпнешь какую-то херню, то чтобы ее подтвердить, приходится городить все большую...

(815) дурака надо бить его же оружием.

(814) Да-с, батенька, выборкой. В процессе создания/перестроения индекса.

(816) Вы нам это по всей этой тебе наглядно демонстрируете.

(817) Прежде чем кого-то называть дураком не лучше ли доку по базам почитать?

(820) судя по вашим амбициозным заявлениям, первые "доки по базам" я читал еще до вашего рождения...
Это, конечно, не показатель того, что я их _тогда_ понял, но это показателоь, что я давно знаю, что такое нормальные формы, и не придумываю херню

Пока делаю вывод при достаточном быстродействии СУБД не нужны
1. Регистры
2. Индексы

(822)+ 3. Кэш тоже к чертям

(822) документы тоже не нужны получается)

(824) модули 1с тоже к черту, пускай все пишут в блокноте и скармливают в выполнить

(824) Многие учетные системы без документов обходятся да
Там только сущности аля справочники

(695) >> Регистр - это идея из докомпьютерного периода.

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

Регистр не является компьютерной идеей. Дело обстоит ровным счетом наоборот. Регистры придумали, когда о компьютерах даже речи не было.
Регистр - это идея из бумажного учета, когда каждая хозяйственная операция требовала, чтобы кто-то сделал запись в большой амбарной книге. В бухгалтерии - это Журнал-ордер (аналог регистра бухгалтерии) и Главная книга (аналог таблиц итогов регистра). У кладовщика - Журнал учета движения товаров на складе (ТОРГ-18). У кассира - кассовая книга. И т.д.
И любые отчеты (хоть складские, хоть бухгалтерские) готовились по этим книгам/журналам, а никак не по документам.

А вообще вопрос проще всего решить, написав готовую конфигурацию без регистров.
Простейшую: учет товаров, учет денег в кассе/на счете и учет взаиморасчетов с поставщиками и покупателями. Приходы, расходы и остатки по каждому из разделов. По товарам помимо суммового разумеется и количественный учет. Ну и разумеется какой-то универсальный инструмент позволяющий менять показатели в отрыве от документов учёта (аналог ОперацияБух в БП или Корректировки в некоторых других конфигурациях).

(825) классическую двухзвенку видел?
на pl/sql (или t-sql) и супертонком клиенте
там вся бизнес логика на хранимках, вьюхах и триггерах
клиент чисто готовые данные берет и показывает или записывает вызовом хранимок

(820) Индекс никак не может относиться к денормализации по той простой причине, что нормализация и денормализация - это про отношения между таблицами. А индекс в этом плане ничего не меняет. Да, покрывающий индекс тоже призван за счет дупликации данных решать проблемы производительности. Но это не дает ему права на знак равенства с термином "денормализация". Вы непозволительно широко трактуете общепринятую терминологию и поэтому выпадаете из диалога.
(822) Так и есть.

(828) вопрос только зачем делать из 1ски 3хзвенки - 2хзвенку?

(829) таки индекс дублирует данные, по сути для ускорения поиска построили допустим дерево и поля (ключи) там продублированы относительно исходной таблички
т.е. можно представить индекс в виде дополнительной таблицы или нескольких таблиц обычных с повторяющимися данными

(820) Ну или приведите выдержку из любой "доки по базам" где индексы обзывают частным случаем денормализации. Не найдете такого.

(831)+ короче в исходной таблице сортировки нет
а индекс это по сути отсортированные по ключам/полям таблички, для быстрого поиска например методом половинного деления

(825) ты изобрел бэйсик! :-)

(833) индексы - это не таблички. это связи

(835) индексы бывают разные

(831) Перечитай мой пост. Я написал, почему эта дупликация не относится к денормализации. Она никак не влияет на отношения между таблицами. Это другой уровень ускорения, более низкий. Или ты тоже топишь за то, что любая дупликация - это денормализация?

(835) Наивный... :)

(821) Судя по (835) действительно ни хрена не понял. Бывает... :)

(837) Ну, тут вопрос терминологии. Хотя соглашусь, что термин "денормализация" не совсем походит, но другой термин пока не подобрали. Дупликация как-то не приживается. :)

(840) Вопрос терминологии - ключевой в диалоге. Если один называет теплое мягким, то можно целый день спорить ни о чем имея в виду одно и то же.

(841) Кстати, возможно вся эта тема возникла из-за вот такого особенного понимания автором термина "регистр"...

(842) Вряд ли, человек со столькими сертификатами по 1с, явно понимает что есть регистры для 1с и для чего они нужны. Но вот какие-то необъяснимые силы заставили его написать статью и придумать волшебную функцию, в которой кругом радуга и пасутся единороги, где все так просто и знакомо, но реальных примеров хотя бы для управленческого учета мы вряд ли увидим...

(843) автору опуса стоит задуматься, зачем нужны константы? когда можно без констант обойтись, тем более сейчас в них чёртечто хранится - "деревья и кустарники" в хренилище значений

Даешь, тему дотянуть до 1000!
Иначе ни как.
Мы же потеряем 1с спеца если не убедим его или же не объясним что он заблуждается.

(843) Его внезапно подкосило осознание несовершенства мира. Мол так как остаток на складе - это функция от документов, было бы здорово, если бы она так и работала, без суррогатов.
Смех смехом, но большинство об этом вообще не задумывается и воспринимает как данность.

(846) только вот, когда начинаешь разрабатывать и внедрять, что то серьезное, то без "суррогатов" уже не обойтись

(847) Но мечтать все равно полезно.

(847) Зависит от объемов этого сурьезного и железа/софта в наличии
Про аналог 1С на NoSQL давно еще я писал, там как раз никаких регистров нет и разница между справочник/документ просто содержимое и поля

(846) Это как мне пришлось сыну во времена его обучения в начальных классах школы объяснять зачем придумали таблицу умножения если и так все легко и просто умножается. Тем более, что устный счет у него как раз был быстрее, чем у всех остальных. Но после объяснений таки скорость устного счета резко возросла :).

(850) Ты по табличке умножения а другой по калькулятору/компьютеру и кто быстрее?
Технологии просто не дошли, потом регистры пойдут на свалку

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

(852) ну да ну да, а без корп лицензии все равно пойдешь лесом, хоть у тебя и супер пупер турбо сервак)

(852) Что бы кто не придумал, а место на дисках УЖЕ настолько дёшево относительно прочего, что наличие доп. таблиц регистров вообще никого не смущает и никому не мешает.

(852) Блин я всю ветку талдычу что уже давно есть минимум два метода "смело расход из прихода вычитать"

1. View в SQL
2. MapReduce в NoSQL

(854) https://3dnews.ru/1037573/defitsit-hdd-i-ssd-neizbegen-esli-kriptovalyuta-chia-vzletit

(854) уже майнить начали на жестких дисках, возможно будет дефицит, как с видеокартами(

(857) ха опоздал см (856)

(852) Тепловыделение никто не отменял. Чем больше вычислительных операций, тем больше греется процессор.

Побежали скупать SSD и HDD пока не пропали или не подорожали ))

(860) Я себе прикупил 2 HDD по 4 Тб Toshiba.

(856) (857) Ну тогда предлагаю всё же изучать абак и счёты, потому как скоро компьютеры будут так дороги, что все эти программы будут невостребованы.

(862) WD надо было брать!!!!

(864) У меня было много WD. Они так же сыпятся, как и Seagate

(859) >Тепловыделение никто не отменял. Чем больше вычислительных операций, тем больше греется процессор.
Зачем пост снесли?

Про водонагреватели это прямая аналогия!

Регистры это накопительный - медленно считаем а затем держим на дисках уже посчитанное
Функции это проточный - считаем быстро на лету когда надо, на дисках ничего не храним

(843) Так каждый хочет быть солнцем, а не серым, как небо.

Видимо секцию Миша хочет свою)

(867) Небо синее

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

(869) Да, Миша, конечно, синее.

(870) гелиевые wd тоже плохи

(872) У ВД раньше была четкая цветовая дифференциация штанов, а последние годы какая-то путаница началась(

Короче, в тот момент, когда кто-то реализует процедуру "быстрого расчета" себестоимости остатка на складах комплекта, созданного комплектацией из нескольких позиций с использованием готовой продукции, произведённой в многопредельном собственном производстве с использованием полуфабрикатов при классической схеме определения фактической производственной себестоимости "стандарт-костинг", на основе импортного сырья с массой доп.затрат на приобретение без использования регистров в базе, которая функционирует хотя бы пару лет, я приму аргументы, что "регистры" - атавизм.

(874) https://habr.com/ru/company/dbtc/blog/498374/
"уай нот?"

(879)+ если всю БД засунуть в память видеокарты то оверхеда по пересылке нет
и тут GPU бьют CPU просто разгромно

(874) У меня, кстати, есть база одной небольшой (но и не совсем маленькой) организации. Как раз за два года. С регистрами, регистрами, не волнуйтесь. Специально делал с нуля, хотя можно было накатить УТ. Да, оптовая торговля. Да, без производства (но с комплектацией-разукомплектацией). Да, без регламентированного учета (но с модулем обмена с БП) Но... 18 метров. За два года. Как понимаете, такое целиком влезет в память 10 раз.

(881) 18мб база?

(882) Угу. Вместе с конфигурацией. Конфигурация 800К

(883) "но и не совсем маленькой" что то мне верится с трудом. У меня самая маленькая база весит 11мб. Но это чисто конфа для мобильного приложения, данных на ней 0. Да и в конфигурации есть только библиотека для сканера и 1 документ.

(883) заинтриговал :)

скрин базопузомера этой базы можешь сделать? ну или https://infostart.ru/public/15052/ если скуль или https://infostart.ru/public/176476/ если файло

(883) сколько документов в год в вашей базе влияющих на остатки? Есть ли учет в разрезе складов, характеристик, подразделений? Сколько наименований номенклатуры, и какой примерно документооборот в год?

(885) Сейчас сделаю

(886) Ну все! Прощай работа ))) Сейчас скажу

(885) Пардон, ребята! Смотрел на размер выгрузки базы, потому что обычно с ним имею дело. Размер CD 240 мб.
https://ibb.co/8Nj1TV1

(855)

(886) Контрагенты 10 тыс. Номенклатура 8 тыс. За два года Заказов покупателей 17 тыс. Соответственно, примерно столько же отгрузок. Плюс поступления, возвраты, расчеты, комплектации. Документооборот около 20 тыс. в год.
Извините, что ввел в заблуждение

Тьфу
(855) Материализованные представления и распараллеливание вычислений? Это нифига не серебрянная пуля.

Можно сказать, что таблицы итогов регистров это и есть материализованные представления.

(892) Это хорошие методы чтобы отказаться от регистров
И они уже давно работают

(894) Типа добавлять по ноде с каждым годом роста базы? :)

(895) угадал ))
еще можно свертку делать схлопывая старые доки в один - но это этакий эрзац регистр по сути с потерей первички

(891) у меня только картинок в номенклатуре для 8к позиций будет весить больше. У вас либо ссылка на картинку, либо их вообще нет в базе...

(896) С горизонтальным масштабированием все не так просто. Конкретно обороты ложатся хорошо, но в целом универсальную систему на NoSQL построить значительно проблематичнее. NoSQL хорош для конкретных решений, так как можно максимально затюниться под задачу.

(898) если задача хорошо параллелится (можно доки обрабатывать группами а уже потом эти группы) то прекрасно масштабируется

(891) какая мелкая хрень.
контрагенты и номенклатура - объемы - вообще непринципиально, у меня у лавочника на 77 ТИС спр.номенклатры был под 120 тыс элементов... порезал неиспользуемой - осталось 70 тыс, сейчас наверное уже снова под 100, не смотрел давно... - правда работает под скулем, но никаких оптимизаций нетрадиционных нет.
.
в основной торговой базе - заявок покупателей - 219 тыс с 2014 по 2020г. и это з апериод когда активность покупателей сильно упала.

(891) это что-то несерьезное. у меня база средненькой конторы была - там документооборот был чуть более 8 тыс.доков в день. (на большие базы я смотрел - мне неуютно становилось)

по нынешним нормативам ваши 25 заявок в день - это 1 торговый, 0.5 комплектовщика, 0.1 кладовщика, менее 0.05 оператора, бухгалтер на уровне статпогрешности. в пределе 2 человека.

-я дом построил!
--поздравляю! сколько комнат?
-Одна!
-- Правильно! Меньше и смысла нет!!!
©

(901) И эти люди учат нас строить учётные системы...

(891) Бугога.
Я больше скажу - если контрагентов штук десять и отгрузок столько же за год, то и компуктер не нужен, не то что регистры.

(889) Мда, Миша в своём репертуаре.