pips34

joined 9 months ago
 

Hello! Let me first clarify, this is for a personal project, based on an idea I always use to learn all kinds of things: personal finance tracking.

The DB model I typically use looks something like this:

Initially, I made the decision to separate incomes, expenses and transfers into separate tables, which makes sense to me, according to the way I learned DB normalization.

But I was wondering if there is any benefit in somehow mixing the expense and income tables (since they are almost identical, and any code around these is always almost identical), or even all 3 (expense, income and transfer). Maybe it is more convenient to have the data modeled like this this for an API, but for BI or analytics, a different format would be more convenient? How would such format look like? Or maybe this would be better for BI and analytics, but for an API it's more convenient to have something different?

A while ago at a previous job, an experienced software architect once suggested, for a transactional system, to separate the transactional DB from a historical DB, and continuously migrate the data differences through ETL's. I have always thought that idea is pretty interesting, so I wonder if it makes sense to try in my little personal project.

If it was you, how would you model personal finance tracking? Is there something you think I may be missing, or that I should look into for DB modeling?

(Note: I intentionally do not track loans / investments, or at least I have not tried to integrate it for the sake of simplicity, and I have no interest in trying YET.)

[–] pips34@programming.dev 1 points 9 months ago

Beautiful! I only reply just now because I JUST got it working. This is exactly what I was looking for, thank you sooo much :) I'm keeping both approaches in a lil template project I have, and definitely checking Serilog next!

[–] pips34@programming.dev 2 points 9 months ago (1 children)

Love it! Works great for me, since most of my services receive only 2 params, and even if I didn't, having 2 or 3 wrappers is no big deal. Tysm! :)

[–] pips34@programming.dev 2 points 9 months ago

Hi, my IDE is PyCharm with the Material theme

 

Hello! I'm starting a personal project in .NET.

For a logging solution, I want to achieve something similar to what I have in a Python REST API I wrote a while back using the decorator pattern (example in the image).

In the example, the outter "log" function receives the logger I want to use, the decorator function receives a function and returns the decorated function ready to be called (this would be the decorator), and the wrapper function receives the same arguments as the function to be decorated (which is a generic (*args, **kwargs) ofc, because it's meant to decorate any function) and returns whatever the return type of the function is (so, Any). In lines 17 - 24 I just call the passed in "func" with the passed in arguments, but in between I wrap it in a try except block and log that the function with name func.__name__ started or finished executing. In practice, using this decorator in Python looks like this:

import logging
from my.decorator.module import log

_logger = logging.getLogger(__name__)

@log(_logger)
def my_func(arg1: Arg1Type, arg2: Arg2Type) -> ReturnType:
    ...

Ofc it's a lot simpler in Python, however I was wondering if it would be possible or even recommended to attempt something similar in C#. I wouldn't mind having to call the function and wrap it manually, something like this:

return RunWithLogs(MyFunction, arg1, arg2);

What I do want to avoid is manually writing the log statements inside the service's business logic, or having to write separate wrappers for each method I want to log. Would be nice to have one generic function or class that I can somehow plug-in to any method and have it log when the call starts and finishes.

Any suggestions? Thanks in advance.