DE
Таблица === сущность
Size: a a a
2021 January 10
НА
не всегда, бывают кейсы, когда группа данных отдельная и не совпадает с структурой бд
DE
не всегда, бывают кейсы, когда группа данных отдельная и не совпадает с структурой бд
Например?
НА
например твоя апишка отдает инфу по юзеру. там много разных данных. и например она поделена по таким отдельным сущностям, user_geo, user_profile, user_statistics. В свагере ты описываешь эти отдельные сущности, а в эти сущности уже добавляешь вручную данные из разных таблиц.
DE
например твоя апишка отдает инфу по юзеру. там много разных данных. и например она поделена по таким отдельным сущностям, user_geo, user_profile, user_statistics. В свагере ты описываешь эти отдельные сущности, а в эти сущности уже добавляешь вручную данные из разных таблиц.
Ну так мы пока не разобрались как это будет храниться.
НА
так тут проблема видна же) чел хочет в определенной сущности "ISyntheticAccountEntity" отдавать поля byDebitAccounts и byCreditAccount. Но незадача в том, что там лежат как раз таки данные той же сущности ISyntheticAccountEntity. суть в том, что если оно так будет работать то при заполнении может рекурсия возникнуть) но организация данных подобным образом остается загадкой для меня) из того что вижу там тупо в таблицу Синтетик аккаунтс надо поле enum добавить вида acccount_type ['credit', 'debit'], но тут по нагрузке надо смотреть
В
Добрый день.
Кто-то знает как в Nest.js прописать в Swagger зависимось сущности самой на себя?
Пробовал
Кто-то знает как в Nest.js прописать в Swagger зависимось сущности самой на себя?
Пробовал
type: () => [SyntheticAccountEntity] и type: () => SyntheticAccountEntity,
isArray: true
, но в доке потом только nullidField, numberField, titleField и тд. Зачем в конце еще field приписывать?
В
idField, numberField, titleField и тд. Зачем в конце еще field приписывать?
В
Мне кажется это излишне и громоздко смотрится
В
Мне кажется это излишне и громоздко смотрится
F
DE
DE
так тут проблема видна же) чел хочет в определенной сущности "ISyntheticAccountEntity" отдавать поля byDebitAccounts и byCreditAccount. Но незадача в том, что там лежат как раз таки данные той же сущности ISyntheticAccountEntity. суть в том, что если оно так будет работать то при заполнении может рекурсия возникнуть) но организация данных подобным образом остается загадкой для меня) из того что вижу там тупо в таблицу Синтетик аккаунтс надо поле enum добавить вида acccount_type ['credit', 'debit'], но тут по нагрузке надо смотреть
Проблема в том, что счёт может подразделяться по трём разным направлениям:
— В зависимости от объекта учёта
— активные
— пассивные
— активно-пассивные
— По степени детализации учёта
— синтетические
— субсчета
— аналитические
— В зависимости от участия сальдо по счёту в формировании бухгалтерского баланса
— балансовые
— забалансовые
По каждому направлению должны провестись раздельные расчеты и всё должно сойтись в конце, так как счёт то один!
— В зависимости от объекта учёта
— активные
— пассивные
— активно-пассивные
— По степени детализации учёта
— синтетические
— субсчета
— аналитические
— В зависимости от участия сальдо по счёту в формировании бухгалтерского баланса
— балансовые
— забалансовые
По каждому направлению должны провестись раздельные расчеты и всё должно сойтись в конце, так как счёт то один!
DE
И каждый счёт имеет две стороны: дебет и кредит
DE
Грубо говоря + и -
AK
Проблема в том, что счёт может подразделяться по трём разным направлениям:
— В зависимости от объекта учёта
— активные
— пассивные
— активно-пассивные
— По степени детализации учёта
— синтетические
— субсчета
— аналитические
— В зависимости от участия сальдо по счёту в формировании бухгалтерского баланса
— балансовые
— забалансовые
По каждому направлению должны провестись раздельные расчеты и всё должно сойтись в конце, так как счёт то один!
— В зависимости от объекта учёта
— активные
— пассивные
— активно-пассивные
— По степени детализации учёта
— синтетические
— субсчета
— аналитические
— В зависимости от участия сальдо по счёту в формировании бухгалтерского баланса
— балансовые
— забалансовые
По каждому направлению должны провестись раздельные расчеты и всё должно сойтись в конце, так как счёт то один!
Ах ты ж молодец
DE
Так вот думаю имеет смысл хранить таблице именно фактические операции поступлений и списаний со счета, имеющих какие-то флаги для их классификации по указанным выше направлениям, а сами отчеты по этим направлениям настроить запросами во вьюхах.
DE
Это будет заранее гарантировать целостность данных и то, что результаты сойдутся в итоге.
DE
И это бы работало, если бы целью бух. учёта было не сокрытие информации, а её демонстрация!
В
бух чё-та