Reorganize database repositories to support multiple products

[JolanThomassin]

Issue Overview:

Right now, each of our databases, like "louis-db" and "nachet-db," is set up just for one product. Imagine it's like having separate drawers for each type of clothing you own. To make things easier and more flexible as we expand our range of products, we need to reorganize these databases so that they can work together for all our products. It's like having one big wardrobe where you can store all your different types of clothes. This will help us be more adaptable and able to handle our growing product variety.

Objective:

The main goal of this task is to change how we organize our databases so that we can have several products working together smoothly in one easy-to-maintain system.

Proposed Changes:

• Rename Current Database: We'll change the name of the existing "louis-db" to "ailab-db" and make it the core database for future development.
• Revise Repository Structure: We'll create a new structure for our repositories that makes it easy to add multiple products. This new structure will allow us to seamlessly integrate new products when they come up.
• Introduce Modular Product Integration: Think of this like building with LEGO blocks. We're going to set up a system where each product is like a unique LEGO block. When we get a new product (a new LEGO block), we can easily connect it to our existing LEGO structure (the database) without taking everything apart. This means we can keep our database well-organized and grow it without causing a mess. Example: Imagine you already have a LEGO house, and you get a new LEGO piece to add to it. With our system, you can simply attach the new piece to your existing house without rebuilding the whole thing.

These changes will enable our database system to adapt to the evolving needs of our product, making it more flexible, maintainable and user-friendly.

Why it's Important:

• Efficiently manage databases for multiple products without duplication or conflicts.
• Streamline the deployment and maintenance process.
• Enhance code quality and reduce the risk of errors.
• Facilitate collaboration among development teams working on different products.

---

ToDo:

• Change Repository Names: Give our repositories new names to match the new structure.
• Organize Python Modules: Rearrange our Python modules to fit the updated repository structure.
• Export Python Packages for Each Product: Make sure each product, like "nachet-db," is neatly packaged and can be easily integrated into the database.
• Update Our Internal Documentation: Keep our internal wiki up-to-date to reflect the changes we're making.
• Automate Deployment: Set up a system to automatically put our changes into action, so we don't have to do it all manually.

[rngadam]

• why you are putting initial caps both in your diagram and names?
  • https://github.com/ai-cfia/dev-rel-docs/blob/main/Naming-Conventions/NAMING-RESOURCES.md
• it's a lot of fancy words (chatgpt verbiage?) without concrete examples
  • please provide concrete examples of how this would apply to us
• diagram is not accurate since it seems you have each box represent a repo, but there won't be an individual repo for each PRODUCT-db but rather modules that are exported from a single python module tree

I'm realizing that editing the description is going to make it difficult to keep track of changes and getting line-specific comments. We also have a need for a more disciplined process akin to RFC (ADR Archirectural Decision Records).

let's make this a PR in dev-rel-docs/adr/002-database-structure.md

here's some guidance on writing RFC:

https://philcalcado.com/2018/11/19/a_structured_rfc_process.html

and ADR:

https://www.youtube.com/watch?v=rwfXkSjFhzc

what this issue should contain is a checklist of things to be done to execute the content of that RFC:

• rename repo
• restructure python module
• export python packages per product (example: nachet-db)
• update internal wiki
• automate deployment

[rngadam]

@JolanThomassin don't forget to reference this issue when you create the ADR PR in dev-rel-docs. there's a github syntax to refer to issues across repositories.