On Apr 9, 2018, at 12:01 PM, Tom Swenson wrote:

> Nice writeup! Makes me sorry that I couldn't fit in time to attend the Summit 
> this year.
> I'll toss in a bit of history - "object" databases. It was a concept that 
> kind of flared up back in the 90s but didn't get any market traction.
> For instance, way back when I was working at Motorola, we tried to use an 
> object database called O2 (example at 
> http://www.db.ucsd.edu/static/cse132b-sp01/o2.pdf 
> <http://www.db.ucsd.edu/static/cse132b-sp01/o2.pdf>) to track requirements. 
> The requirements for cellular system features were done in the hierarchical 
> milspec fashion of 1.1.2,,, etc. so it seemed that a database 
> with inheritance, etc. would fit. Ah well, another fine idea tried before its 
> time - the user interface and development platform was all a bunch of command 
> line stuff and it was clumsy trying to get it to connect to all the other 
> bits and pieces of the organization. I ended up throwing together a 4D 
> system, serve it to some web pages and declaring victory.
> Fast forward, I _love_ the idea of dot notation. This seems like 4D could be 
> getting back to its sweet spot of being able to generate an application/web 
> app/client server db by small groups or single developers. Trying to build an 
> integrated app using one (usually many cobbled together) of the javascript 
> frameworks for android/ios/electron to get the full combination of platforms 
> desired along with all of the fun, maybe-secure, maybe-maintained, node 
> libraries and who knows what else dependencies is a ticket to a failed 
> business plan.

Something that may not be immediately obvious is that using ORDA will reduce 
the amount of code needed to query the database. In relational databases you 
have to query this table, join to another table, query selection, relate many, 
etc. We are all used to doing this and we need to know exactly what the 
database structure is. What table is the one table, what table is the many 
table, is there a many-to-many intermediate table we need to deal with, etc. 

ORDA can remove the need to know this level of detail in many cases. By naming 
relations in a “logical” way you can write code to get the “manager” of an 
employee, or get the “direct reports" for an employee. And from that you can 
then further filter the results by using a “query” member function. You let the 
4D database figure out if it needs to relate many selection, or relate one 
selection for you. And you can make these named relations very complex if you 
want. There is a lot of power here that is just starting to be exposed. 

We have not even started to talk about the super powerful “member functions". 
“Query” is a common one used on a database class or “entity selection”. 
Terminology is still new to me so I may not be using the right words. But we 
will be able, in the future, to create our own “member functions”. So it can do 
much more complex things than the built in member functions like “minimum”, 
“sum”, “average”, etc.

Tim Nevels 
timnev...@mac.com <mailto:timnev...@mac.com>
Innovative Solutions

4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com

Reply via email to