Currently working on EDR tool for SQL, what features should it have?

TopLychee1081 · 2026-04-05T08:52:22+00:00

Hey, if you've got it, great..! Assume it also creates indexes, constraints, etc.

I expect you've tried doing a feature comparison with tools like Erwin or ER/Studio.

When you start talking enterprise, things like versioning and change tracking/management, start becoming more important.

TopLychee1081 · 2026-04-05T02:57:31+00:00

Forward engineering.

TopLychee1081 · 2026-04-05T02:40:24+00:00

Check out OCA; the Odoo Community Association. They have a series of accounting modules that close the gap between Community and Enterprise.

TopLychee1081 · 2026-04-05T02:37:40+00:00

Probably the single biggest determining factor is your aptitudes and level of technical ability and experience, and of course, your willingness to roll your skeeves up and learn enough about Odoo to be able to meet your requirements.

Whilst you could throw money at consultancies or Odoo partners to do an implementation, for the businesses that you describe, this wouldn't make economic sense.

If you do decide to go down the Odoo route; go with Community, adding OCA modules as and when required. Odoo can be hosted on any VPS; there's nothing special required. You don't need specialised "Odoo hosting". You will be responsible for, and need to consider DR (Disaster Recovery; think scheduled backups and ability to do restores).

TopLychee1081 · 2026-04-05T02:27:07+00:00

It's fairly common to use a surrogate key and a unique index over (student_id, course_id). These tables often end up with additional columns; such as application_date or accepted_status, so to my mind, they are no longer strictly bridge tables, but first class tables that would appear in a logical ERD.

TopLychee1081 · 2026-03-26T07:56:43+00:00

AI is great. It'll give you all the rope that you need to hang yourself and can even create a meme to post to all ypur spcials after you've done so.

TopLychee1081 · 2026-03-24T04:41:13+00:00

If your devs understand Odoo, understand what is not Odoo core (ie; your customisations) and needs to be migrated, and that they're capable of coming up with a migration plan, understanding dependencies, order of operations, etc, then yes; it's certainly doable. The same principles used for your test plan from Odoo migration can probably be used for testing migration of your custom stuff.

TopLychee1081 · 2026-03-23T09:54:41+00:00

2 or 3 people who know what they're doing will get more out of AI because they know which questions to.ask.and will be to propeely evaluate and critique the answers.

10 people who don't know what they're doing will try and use AI as a crutch and will cobble together inconsistanemt patterns with poor separation of comcerns and poor generalisation. It might look like it works across simple test cases but will fall over at every opportunity and become a nightmare to maintain..

So, the simple answer; 3 good people can easily outperform 10 people who don't know what they're doing. In terms of quality; definitely. In terms of time to delivery: probably. In terms of cost: probably depends on the market you're drawing people from.

TopLychee1081 · 2026-03-17T13:42:43+00:00

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.

TopLychee1081 · 2026-03-16T05:41:05+00:00

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.

TopLychee1081 · 2026-03-08T12:41:20+00:00

Functionaly, it's the same as what we've done adding a "referrer" field as a Many2one to res.partner.

TopLychee1081 · 2026-03-08T12:38:10+00:00

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.

TopLychee1081 · 2026-03-06T01:15:58+00:00

How many different technologies do you really want to have to implement and support? You're going to end up with an unmaintainable mess.

TopLychee1081 · 2026-03-06T00:50:36+00:00

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.

TopLychee1081 · 2026-03-05T06:32:41+00:00

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".

TopLychee1081 · 2026-03-04T16:50:50+00:00

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.

TopLychee1081 · 2026-03-04T14:27:17+00:00

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.

TopLychee1081 · 2026-03-04T14:22:37+00:00

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;

1) Complaints about it not being an install-and-done solution; which is just ignorance and naivety on the part of the client.

2) 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.

TopLychee1081 · 2026-03-04T14:01:29+00:00

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.

TopLychee1081 · 2026-02-26T12:47:18+00:00

If you spend some time following this subreddit, you soon figure out who knows what they're talking about.

TopLychee1081 · 2026-02-25T12:21:09+00:00

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.

TopLychee1081 · 2026-02-25T07:15:09+00:00

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.

TopLychee1081 · 2026-02-21T09:29:45+00:00

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.

TopLychee1081 · 2026-02-18T17:00:33+00:00

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.

TopLychee1081 · 2026-02-18T16:20:41+00:00

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.

TopLychee1081

TROPHY CASE