Pull to refresh
0
0
Евгений @MinimaJack

Программист

Send message

предложите варианты решения… что делать когда сотни связанных данных?


Я вижу всего 2 варианта работы в реляционной БД: либо жесткая денормализация, либо join-ы.


Как вариант выкинуть реляционные и использовать графовые БД, но они не так давно то и появились(хорошего уровня) — и у них свои проблемы...

Вы в своей практике делали маппинг в базу объектов( с наследованием) или вы только мечтаете о таком?


Я бы тоже не отказался… еще и автоматический, еще бы и с миграциями)
Да я скорее откажусь от наследования — чем соглашусь руками все прописывать)

Ну а где по вашему хранятся дополнительные реквизиты?


Одно дело использовать ООП для объектов хранящихся в памяти — другое дело смапить все ООП и данные в БД. Да, это возможно — но это очень и очень неудобно. А говорить об адекватной миграции, изменении классов родителей — так вообще жуть.

Ну так в 1С и есть композиция...


Neikist puyol_dev2 вот вы реально думаете что станет лучше и легче? Вот эта та кнопка которая все сделает?


Ок… будет 100 похожих документов, что будет с их хранением? В разных таблицах или одной? Что будет с производительностью join-ов? Что с нормализацией базы? Как будут происходить миграции? Вы думали как раздуются запросы?

Neikist
Что удобней? Получить 20 разных документов — или несколько лишних реквизитов?

Можно бизнес-пример, а не перламутровые пуговицы?
Обычно документы связаны логически, если одинаковые добавляют "Вид операции"...

В lsFusion можно написать FOR, но он в большинстве случаев скомпилируется в один SQL запрос.

То есть возможна ситуация с некачественной генерацией. Чего в 1С можно избежать запросом… правильно я вас понял?


Если у вас сервак в облаке то очень критично. Собственно зайдите на demo-ma.1c.ru.

Никто ж не говорит что стандартные конфигурации идеально оптимизированы


Ну про SQL вы не ответили. А про native api это вы это имеете ввиду? Очень бесшовно.

Достаточно раз написать и обернуть удобным образом...lsFusion позволяет подключать dll, позволяет работать с Com-компонентами — бесшовно?


Ну то есть язык убогий, чуть менее чем полностью

И вы не понимаете что это далеко не главное?

Так в 1С если в цикле обращаться по ссылке, то для 100 записей будет 100 запросов. Собственно поэтому 1С и рекомендует везде писать SQL запросы руками (то есть грубо говоря забить на 1С)

Грубо говоря — для разных задач 1С позволяет использовать разный инструмент — правильно? Где то можно и по ссылке использовать, где то оптимальным будет запрос написать… в чем минус то? В lsFusion — нельзя написать запрос в цикле?


Эффективное общение клиента с сервером

25 вызовов… на любом следующем 4 — это ж хорошо — часть данных закешировалась… Конечно идеально было бы один вызов всегда, но так ли это смертельно; веб сайты не сильно отличаются обновил страницу хабра — 50 запросов.
В 1С есть и шифрование и сжатие...


Ну расскажите, как в 1С сторонний код подключить к серверу приложений

внешние компоненты по технологии native api, и да в 1С я могу и java библиотеки использовать...


Ну и как в 1С к примеру с явной типизацией или замыканиями?

никак с типизацией и замыканиями, это не типизированный и не функциональный язык… я даже больше скажу там операций инкремента на единицу нет...

Так как мы не можем один класс наследовать от другого дважды, то для того, чтобы провести по регистру повторно, создадим агрегированный объект нового класса TransferSkuLedger, который затем наследуем от SkuLedger

Что то не убедили в целесообразности...

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


Просто это отклонения от общепринятых стандартнов

Да я и сам разрабатывал такие формы...

В платформе 1С нет контроля за остатками. Что сравниваем?


В lsFusion ничего этого делать не надо — что значит не надо? Не надо как для конфигурации или как для платформы?

LeshaLS
DAleby
Да никто не спорит с этим… только в 1С нет "фигур для которых надо считать площадь". Можно пример бизнес задачи — где такое может потребоваться?

При стандартном подходе 1С — один документ много строк. Но никто не мешает сделать один документ на строку, и один документ-владелец.


Получится такой же эффект — просто никому это не надо...

А можно увидеть пример списания партий, что бы это было вот как вы пишете прям в платформе!
Что бы можно было настроить FIFO, FEFO, LIFO — вот прям в интерфейсе?

При чем ООП и дублирование кода?
В 1С есть общие модули, формы и т.п. и ничего адекватному программисту не мешает выделить дублированный код в отдельную функцию…
Да — очень много похожего кода… но он разный

А что там аргументировать? Вы перейдите и посмотрите…
"No ORM, Yes SQL"
"Эффективное общение клиента с сервером"
"Бесшовное подключение Java-библиотек / SQL-функций"
"Эргономичный язык"

Красиво можете "1+1=2" написать, давайте не сравнивать платформу и конфигурацию.
Все сводится к одному: в платформе 1С нет встроенного контроля отрицательных остатков. Все!
А вот вопрос его целесообразности — это уже вкусовщина

формирование движений будет происходить в любой системе кодом. Если там что то сложнее от склад, товар, количество.


Запись в регистр, да возможно где то и автоматом… но по секрету, в 1С тоже можно автоматом — просто это медленнее.


"Запись движений при проведении" — "Записывать модифицированные" — можете погуглить

Information

Rating
Does not participate
Location
Республика Крым, Россия
Date of birth
Registered
Activity