I see the point being made by many in this thread. I am not against
expanding SQLite's functionality. But, if I might, I will throw out some
contrarian ideas. First is that SQLite really is an embedded SQL data base.
It is meant to be combined into your application's main executable file. So
the larger you make the basic SQLite engine, the more "bloat" in the
applications which use it. Of course, a good developer is going to set up
all the proper SQLite #define variables to reduce SQLite's footprint to be
only as functional a possible. This is the proper thing to do. The problem,
if there is one, is that the more "options" that can be enabled/disabled
via #define variables, the more variants exist of SQLite. And the more
difficult it is to test every possible variant. Remember, adding just one
more #define for an "optional" function doubles the number of variants.
This is a quite a bit of work to ask of Dr. Hipp for a completely free
software product.
Another thing that I wonder is why people want all of this in an _embedded_
SQL engine? If somebody really needs a full blown relational database
management system, I really think that a client/server model is superior.
Yes, I agree, this is just my opinion. You can have a different one and
neither of us is really "wrong". I love SQLite for a number of things that
I do. But when I want a multi-gigabyte database used by multiple
applications, I go with PostgreSQL. And, yes, I'm aware that there are such
DBs based on SQLite. But I find the "extras" which come with the
client/server model RDBMS fill a great need. One which I must write myself
when I use SQLite, or find one already written by someone else that I can
adopt/adapt. I mentioned PostgreSQL instead of Oracle or MS SQL Server
mainly due to cost and licensing fees. PostgreSQL is FOSS and basically
allows you to "close source" not only your apps, but any mods to PostgreSQL
that you want to. Very similar to the 2-clause BSD and MIT licenses. In
addition, there is a commercial version, EDB, for people who want or need
professional maintenance, such as many larger companies like to have.
SQLite also has such paid support, if needed.
Well, I've just put up a couple of my thoughts. That's all they are. Maybe
some points for polite discussion. Or maybe I'm just more comfortable with
the way that I already do things. {shrug} What do you expect from a person
near retirement?
On Fri, May 4, 2018 at 2:33 PM, cherie <vg.vikasgu...@gmail.com> wrote:
>
> In 2008 I was part of a project which was mostly DB driven using Sybase
> 12.5. Sybase neither had support for user functions nor window functions &
> many other features, which other contemporary RDBMS had and same arguments
> was thrown why you need user functions or window functions if both can be
> accomplished by stored procedures. Version 1 release (early 2009) ended up
> with around 200 tables, 250 views and roughly 600 stored procs.
>
> Now after 10 years Sybase 15.7 has introduced user functions (and many
> other
> new features) saying it reduces TCO/time-to-market. Now my same application
> has grown to 500 tables, 410 views and 2600 stored procs. Most of these
> procs are repetitive codes with hard to read complex SQL written by
> developers mostly accomplishing reporting needs that grew in years (as
> application stabilized). And looking at those procs I can very clearly say
> that these are nothing but workarounds cooked to achieve what window
> functions provide in very easy to implement manner to developers. Every now
> and then we keep getting alerts that one of the proc is non performing or
> slow etc.
>
> I would love to see window function (before I die) being introduced in
> SQLite to reduce TCO because these output are anyhow being written in java,
> python or wherever if not in SQLite SQL, how its reducing the overall space
> footprint in android, I am not sure. 10 lines of window function can be
> achieved by 100 lines of CTE based SQL and if you do not have developers
> with SQL inclination they end up writing same in one language or the other.
> Think of testing effort that goes in verifying these codes.
>
> Everything in computer can done by machine/assembly codes, then why to use
> Java or C (its simplicity).
>
> -- Abstraction_(computer_science)
> <https://en.wikipedia.org/wiki/Abstraction_(computer_science)>
>
>
>
> --
> Sent from: http://sqlite.1065341.n5.nabble.com/
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.
Maranatha! <><
John McKown
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
