0

I have recently discovered PyKE, and noticed that one of the given examples of a potential use (actually, the use for which it was originally built) was to compile SELECT statements to query a database, and map the result to a dictionary. The author emphasizes that this is not an ORM.

From this, I have two sub-questions:

  1. How is that usage of PyKE (or another expert system capable of executing or emitting code or returning structured data for use by a calling program) not effectively an ORM?
  2. In what circumstances would it be preferable to use an expert system (such as PyKE) to query a database, as opposed to a purpose-built ORM? I assume there must be some, given that PyKE was made for the purpose.
Vivian
  • 1,539
  • 14
  • 38

1 Answers1

2

To your first question

An ORM is a layer between your logic and data that maps one to the other. Relational DBs often don't store data the way your objects use that data, so ORMs aim to abstract away the mental gymnastics needed to write the SQL to transform the data from one representation to another. (imho, They tend not to do it well or efficiently)

For PyKE specifically, one aspect offers SELECT compilation, but not apparently CRUDing (CRUD: Create, Read, Update, Delete), which is the most important thing an ORM does.

On the second question

PyKE would be used for when you might need a knowledge engine (natural language data search, for instance). Then PyKE may know how to extract the data from the database in the most efficient way to complete its own goals.

An ORM, on the other hand, would be given the data that represents some object in your program, such as a purchase order from a website, and it would insert the object when the PO is created, get it out of the DB when a session is restored, alter the data as the user adds and removes items to the PO, and remove the PO if the purchase is completed or aborted (CRUD).

tldr

PyKE is a specialized library that abstracts away some of the need to write SQL to use the library, but doesn't offer a complete set of DB interaction, because that's not what it was built for.

ORMs do offer this interaction with DBs, and attempt to make it easier to use data in a very dynamic way; though in my experience to use / not to use an ORM over hand crafted SQL sparks some pretty fierce debates.

Community
  • 1
  • 1
GMBill
  • 328
  • 4
  • 12
  • But... it's capable of compiling SELECT statements, sending them to the database, etc. Could it not then also be capable of compiling and running other statements for full CRUD, given appropriate rules/plans? Alternately, if e.g. you only needed to use the database in a read-only fashion so you only needed SELECT, why would an ORM be better for the job (if it would be)? – Vivian Sep 15 '16 at 14:17
  • So, I suppose it's possible that if you set it up just right, you can get it to do what you're looking for; but it seems to me that you're using a chisel as a screwdriver. If your question is something like _"I am using this library in a certain way, can't I use it for this other thing instead of importing another library"_ then... You probably could, but I probably wouldn't. – GMBill Sep 16 '16 at 13:45