best way to access databases in different projects (self.python)

submitted 4 months ago by driving_crooner to c/python@programming.dev

18 comments fedilink hide all child comments

Hi, I want to know what is the best way to keep the databases I use in different projects? I use a lot of CSVs that I need to prepare every time I'm working with them (I just copy paste the code from other projects) but would like to make some module that I can import and it have all the processes of the databases for example for this database I usually do columns = [(configuration of, my columns)], names = [names], dates = [list of columns dates], dtypes ={column: type},

then database_1 = pd.read_fwf(**kwargs), database_2 = pd.read_fwf(**kwargs), database_3 = pd.read_fwf(**kwargs)...

Then database = pd.concat([database_1...])

But I would like to have a module that I could import and have all my databases and configuration of ETL in it so I could just do something like 'database = my_module.dabase' to import the database, without all that process everytime.

Thanks for any help.

you are viewing a single comment's thread
view the rest of the comments

[-] odium@programming.dev 1 points 4 months ago

What are you trying to output in the end (dashboard? Report? Table?), how often are these inputs coming in, and how often do you run your process?

[-] driving_crooner 2 points 4 months ago

There's some reports that need to be run monthly, they need to be edited each month to add the directories with the new databases and it causes problems, some of them im trying to solve with this. There's also a lot of ad hoc statistics studies I need to do, that use the same bases.

[-] 4am@lemm.ee 2 points 4 months ago

It does sound to me like ingesting all these different formats into a normalized database (aka data warehousing) and then building your tools to report from that centralized warehouse is the way to go. Your warehouse could also track ingestion dates, original format converted from, etc. and then your tools only need to know that one source of truth.

Is there any reason not to build this as a two-step process of 1) ingestion to a central database and 2) reporting from said database?