Table and Query Classes good or unnecessary?

hi mats.

we use query classes a lot. they are so simple very simple it is not funny. and yes, it is like a view in postgres

but there are advantages of keeping them in studio.

1) you can join many tables and get performance out of it.
2) you can introduce calculated items and functions into the query
3) we regularly UPDATE against a query class that is across multiple tables by focusing on the primary table. this dramatically simplifies code since ANY table class, based on ANY query can be used in omnis with functions like Andreas mentioned in

do list.$myFunction

4) query classes are just a list of fields — very simple documentation since you know what can be updated

5) you don’t have to give up complex sql when you want it in your functions.

6) the table class is linked directly to data which is perhaps the most important concept

7) and if you want to do background sql — you can do that too.

of course you can do that in objects and we put table classes in objects — but the simplicity of defining the data list that matches your sql needs is fantastic … just by putting another column in your query — it self documents.

the notion of adding another class to your project is spurious at best. a query class has no code. its just a list of data fields.

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug@artsman.com
www.artsman.com
Phone (403) 650-1978

see you at the third annual users conference
tickets.proctors.org/TheatreManager/95/online?performance=29086 <tickets.proctors.org/TheatreManager/95/online?performance=29086>

> On Mar 3, 2018, at 11:34 PM, ADJob <mats@adjob.se> wrote:
>
> Hi Das & Co,
>
>> I open this topic with this mood: Not to make a caustic discussion happen, but to find out what benefits these two class types give in a sober, calm way hopefully. Any responders are asked to keep it to the facts and leave out love of them, emotions, etc. Keep it only to the facts of what they do, what they offer, what can be done only with them, etc.
>
> My main reasons to use object classes and avoid table classes are:
>
> 1. Many extra (redudant?) classes
> ————————————————————————
> As you have to have at least 1 table class linked with each schema class, there will be 100+ extra classes to manage for me. If the table class were built into a schema class, it should be smarter IMHO.
>
> Meaning the more classes the harder to search and maintain (400 normal classes (windows, objects etc) + 100 extra table classes)
>
>
> 2. Orphan table classes
> ————————————————————————
> Many of my queries uses several schema classes. Very common.
> This means that you cannot logically link this table class to one schema. You have to use ”Orphan” unlinked Table Classes (In my world these are equal to Object Classes)
> OR link this multi shema table class to a random schema class.
>
> SELECT id, name FROM table 1
> UNION
> SELECT id, name FROM table 2
>
> Meaning the main reason to use table classes is broken.
>
>
> 3. SQL support
> ————————————————————————
> Using plain SQL it is easier to get qualified support via StackOverflow. SO members cannot even spell to Omnis Studio.
> Omnis Support are good at basic SQL, but it is not their cup of tea. But beyond basic is StackOverflow outstanding.
>
> Meaning that mainly doing all in plain SQL it is easier to also communicate with professionals outside the Omnis community.
>
>
> —
>
>
> My main reasons to avoid query classes are:
>
> 1. Non standard approach
> ————————————————————————
> A query class to me is equal to a Postgresql view. I e a stored query you can re-use (= views are simpler than and not equal to a Postgresql functions). But Omnis makes views = query classes hard to understand. Backward SQL?
> I find the Postgresql build in views are way simpler to understand, use and maintain.
>
> SELECT * FROM table1_view WHERE id=1
>
> Meaning that I do not understand ho to use query classes.
>
>
>
> The table classes seems to be very good and smart, so it is more of programming style if you use them or not.
>
> But query classes IMHO are very hard to understand and maintain. Use Postgresql views instead = very smart and way simpler.
>
> FWIW,
>
>
>
> /Mats
> _____________________________________________________________
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com

_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com