What you're trying to do is a "vertical partitioning anti-pattern". If it's the same animal, it belongs in the same table. RDBMS' are designed to handle large volumes of data. What does get critical as volumes grow is indexes that support your queries, proper data typing, and fill factor.
I don't want to yuck your yum, but if you're even considering table per chat, you're so early in your learning journey that what you're looking to achieve is just way too ambitious.
Learn the basics of data modelling and how a RDBMS works first. Then, take that knowledge and apply it to your use case; a chat application, as an exercise. Specifically, you'll want to learn about data normalisation, data redundency; and how it leads to data anomolies, design patterns (such as supertype/subtype), many to many relationships through bridge tables, and how RDBMS' store data; paging, btrees, indexes, and what ACID principles are.
And just to keep some perspective, perhaps learn a bit about graph databases, which is a different paradigm. The more tools in your toolbox, the better the chance that you pick the right tool for the job.
Functionaly, it's the same as what we've done adding a "referrer" field as a Many2one to res.partner.
The first question will always be: What are the data volumes. That determines how much you can afford to spend in time and money developing an import solution before it just becomes cheaper and easier to just key it by hand.
The greater the data volumes and the more complex the data, the greater the chances of errors in keying.
The more conformed your data is, the easier it will be to automate a solution. Data coming from a database will generally be better quality as it's strongly typed and constrained. Data coming from Excel can have all sorts of anomolies and issues due to its open nature.
Whether automating a solution, or manually keying, you'll want to have a plan for how you test to ensure completeness and accuracy.
If automating the solution, then ensure you're developing and testing against a non-production instance. Be prepared to trash the database and restore multiple times as you interate to deal with issues.
How many different technologies do you really want to have to implement and support? You're going to end up with an unmaintainable mess.
This really smells of an organisation that doesn't understand IT projects and change management. There are clear roles and responsibilities for such a programme of work if you're to be successful. Having non technical people specify implementation is a recipe for disaster.
I used to be said that tools like Excel gave users enough rope to hang themselves. AI is going to be a total nightmare. Businesses are going to get themselves in such a mess trying to do things that they just don't have the skills for. I suspect many will blame thier tools and Odoo will be in the firing line with stupid statements like; "Odoo is shit. You can't customise it with AI without it breaking".
Not comparing Boeing engineers to Odoo partners at all. We should be able to, but alas, we can't.
With the right skills, the right expectations, and treating implementation as change management, Odoo can be a great tool.
Everyone seems to be drunk on AI thesedays. They think it's the answer to every problem. And those who trumpet it the most are those who know the least.
I've actually experienced open hostility for having the knowledge and experience to know which things should be done without AI.
Over 10 years running Odoo, and we've never paid a penny to Odoo SA.
Every complaint that I hear about Odoo tends to fall into one of two types;
Complaints about it not being an install-and-done solution; which is just ignorance and naivety on the part of the client.
Related to Odoo SA; making unreasonable promises, taking advantage of clients' lack of knowledge, poor support, and a poor partner program that promotes conversions over quality.
Because Odoo can fit a budget for smaller businesses where SAP is just a dream, it does attract businesses that are inexperienced implementing IT and business change projects. This does result in pain and disappointment.
I must confess to finding it a bit difficult to feel sorry for them, when watching a few Youtube videos, will soon show you that there's more to implementing an ERP than installing a piece of software.
If you implement an open source solution, then you DO own your solution. If you don't have the knowledge or skills to understand it; that's on you. Do you think airlines complain about Boeing because they need pilots to fly their planes and engineers to maintain them?
Sounds very much like you made an uninformed decision, regret it, and want to blame anyone but yourself. You had every opportunity to educate yourself, but you clearly didn't.
If you spend some time following this subreddit, you soon figure out who knows what they're talking about.
Read the work of Codd and learn about normalisation; at least up to 3rd normal form. Being able to generalise is a skill that even many established devs are not great at; and it's essential to good data modelling. Learn design patterns like supertype/subtype, and name/value pairs for extensibility. If what you're looking to build is for your own learning, then that's great. Just don't be afraid to refactor as you learn better ways to do things.
If you need to ask such questions, I'd suggest that you're not ready to start building solutions. Perhaps try getting a job providing support of an existing system, and perhaps small enhancements so that you can gain experience; ideally in an environment where you have a senior dev to learn from.
The integration solution by ERPGAP uses GraphQL. They have a repo that includes the required Odoo modules. The Alokai implementation will then use graph queries to do its thing.
I'm taking a look at Alokai for headless Odoo. The GitHub repo for the Odoo modules has a requirements.txt file with requirements that are not version pinned;
graphene
graphql_server
redis
markdown
Allowing PIP to install them results in successful install, but there are dependency issues between the graphql packages installed. I've tried pinning to various versions, but nothing seems to work.
Can anyone suggests a requirements.txt that works for the Alokai modules.
EDIT:
Ok, OCA haven't yet ported the graphql_base module to Odoo18, so the version included in the Alokai repo must have been ported by them. It lacks the bug fix applied to the manifest by OCA;
"external_dependencies": {"python": ["graphene", "graphql_server==3.0.0b7"]},
Adding the version pinning to this version in the requirements.txt for the Alokai requirement fixed the problem.
Except that when the user first visits a category page without any filtering, they'll see what appear to be duplicated products (assuming that the same primary image is used for each size of a given style of shoe).
Another issue is partners. We've dealt with many partner platforms (dropshippers, affiliate platforms, etc) that expect us to use variations for common attributes rather than a flat catalogue. If you don't define your products to their satisfaction, they'll just remove the offending products or reject your catalogue.
I think you can largly solve the question by asking yourself how a customer would expect to see a product. In some cases, there will be industry conventions, and you'll want to maintain consistency of user experience.
It sounds like you do have variable products. Imagine how annoying it would be if, for example, you were browsing an e-commerce store for shoes and every size of every design was a first-class product. You'd spend half your time scrolling past identical product images to get to the next style.
Personally, I'd have an issue with that. Have you looked into printing using your browser in kiosk mode?
That does make sense as Odoo alone can't control anything outside of the sandboxed environment of the browser. I would hope that the extra install is a trusted third-party solution and not something that the vendor on the app store has come up with. Is the download link to a trusted source; ideally open source?
You're right to be sceptical. What is it that they're claiming the executable is for?
Depends entirely on the business. What is absolutely essential for one business is totally redundant for another.
Don't we have a word for people who can take a structured approach to architecting a solution and unambiguously articulate a requirement to a computer; AI or otherwise? It's on the tip of my tongue...
You might need to articulate your requirements a little better before anyone can get help you.
Odoo community is freely available on GitHub and is licensed as LGPLv3. You can use it and extend it to your hearts content.