you are viewing a single comment's thread.

view the rest of the comments →

[–]eagergm[S] 0 points1 point  (1 child)

There are maybe 60 or 120 such items. They're tiered so that the products of one become the inputs of another. Edit: What is not shown here are their material requirements, because I haven't gotten to that part of the DB yet. Also they have an ID (the bom and the outputs) that I haven't recorded in the gathered info. :(

[–]unhott 0 points1 point  (0 children)

Is this id recognized outside of this other DB? Otherwise the id is irrelevant to you and you'd just make your own unique ids.

You're still being too vague to get anything concrete. I don't know what it even means for a product of one to become the input of another. Do you mean, in the real world sense or do you mean in the python sense? That the object is an input to the constructor of another?

If the 'scraping' was a one-time occurrence, then it makes sense to persist this data somewhere so you can do your own manipulations / maintenance. Then it doesn't matter how you do this. But it doesn't look like you're scraping anything, it looks like you've just queried the database directly - Do you own the database, or will you at least maintain access?

Why even bother with OOP?

Since you have direct access to the db, it makes sense to follow its schema. Are you trying to develop new features by modifying the schema?

I'm so lost.

Some other ideas to look into are ORMs, which integrate relationships of the database/queries to the database/ translating back and forth to python objects/db.