Clash of the Backends leaves Developer stunned
Hi Das,
Here are a few points to consider:
1. If you try to support multiple backends, you’ll get to use the least common denominator between them. If you want to use a feature and one backend doesn’t support it, too bad. You can’t use the feature.
2. Writing your app is just half the story. You also need to deploy and maintain it. If your clients are smaller companies, it’s likely they don’t have full time IT staff. This means A) you’re going to be the one helping them deploy and manage the backend and B) they don’t care what that backend is
3. If you _are_ the one deploying and maintaining the backend, only supporting one backend will save you time and headache. Do you really want to be an ops engineer/DBA for multiple database systems AND an Omnis developer?
4. PostgreSQL is free and deploys to virtually every OS. If you’re going to stick to one backend, PostgreSQL is a good one. And yes, I’m highly opinionated on this, but many other developers here share my opinion.
Alex
> On Feb 2, 2018, at 17:11, Das Goravani <das@goravani.com> wrote:
>
>
> So I’ve heard from a number of Omnis/SQL Gurus on the subject of “Generic SQL” and Backends.
>
> One told me to stick to the Standard SQL as much as possible for portability. Other amongst the knowing tell me that there are multiple standards and besides the backends give differing results for the same commands, and that trying to handle multiple backends is a pain.
>
> So my very general question is this: Should one tell oneself that they are trying to stick to the standard? Should one try at all?
>
> I just had the case where I need to “cast” my numeric field to text so that I can do a LIKE comparison in a Where Clause. I was given two ways of casting… one is to write cast() in front of the column name in question, and the other is Postgres’s way where you say name::text to cast it to text. I’m using a Postgres server as I develop, and it does not recognize the first method, only it’s own method.
>
> So as I sit here I’m faced with “Have bugs now”. I either can run in dev mode with this Postgres server and do things it’s way or face bugs now. Weird. I’d have to fork now for differing backends and I can see as Alex said that “That is a pain”. I can see that. I don’t want that.
>
> The clientele I’ll be aiming at in my “practice” when I’ve learnt enough to “get out there” will be smaller companies, because I work alone. I believe that smaller means “not as stuck on what backend they want to use” as larger corporations who may already have a standard they stick to. So I am MORE OK with just Postgres than if I were targeting the very large companies.
>
> What to tell myself ? Which way to develop in the here and now ? I don’t want to fork all over the place for different DAMS and backends. I can barely do what I’m doing, I mean it’s a hard learning curve as is. What to do brothers and sisters in arms ? What to do?
>
> _____________________________________________________________
> 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
