|
It might be a little primitive for my needs.
While no current projects require any real concurrency on writes I might certainly need it in the future, but particularly, I'd like a bit more data integrity than what you demonstrated above.
Thanks though. Isn't that an in memory capable DB or am I thinking of another one? There was one I was considering using in my projects as a kind of queryable dataset system.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
SQLite can certainly be used as an in-memory database, but only within the context of a single process. So maybe not useful in your use case
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Well, not for this scenario, but the dataset thing was intended for single process, in memory stuff. Think Datasets in .NET but for C++, for example, and queryable.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
We dropped SQL Server in favor of PostgreSQL years ago, and never looked back. It has been multi-platform for a long time and is very stable. The only thing I regret is that they decided to use Python for the PgAdmin tool, the older version was written in C++ and much "leaner and meaner".
|
|
|
|
|
SQL for Linux is a good, reliable product. From experience...
If you are looking for something more multi-platform, go fro MySQL - a very good product too. Also from experience...
"It never ceases to amaze me that a spacecraft launched in 1977 can be fixed remotely from Earth." ― Brian Cox
|
|
|
|
|
When you look for things, look for ANSI SQL.
Those are the common bits across the things SQL.
There are a few implementation/platform specific things. Like Oracle does 'sequences' and MSSQL has 'identity'.
But a big swath of most standard DDL/DML is highly portable.
And I'd say what I think really matters in RDBMS is more about set theory than it is about SQL dialects/specifics. Normalized vs denormalized and stuff like how to identify where indexes are going to help or where they may be more costly (in disk space and maintenance) than the ROI (in performance).
|
|
|
|
|
I believe SQL92 is ANSI?
Also my big concern isn't language, but actual maintenance of the DB.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
One of the good things about PostgreSQL is that it does not need as much maintenance as SQL Server. Our customers usually don't have the skills to maintain an SQL Server properly. Of course this is dependent on how complex the database is.
|
|
|
|
|
Yeah I think so.
"These editions colloquially became known as SQL-86, SQL-89, and SQL-92. So, if you hear those names in reference to an SQL format, note that it is referring the various editions of this standard."
Read more at the ANSI Blog: The SQL Standard – ISO/IEC 9075:2023 (ANSI X3.135) https://blog.ansi.org/?p=158690
|
|
|
|
|
I wrote a SQL92 parser once so I'm pretty familiar with it except I often mix T-SQL in with SQL92 because the lines always blur for me.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
One is inside the other, SQL92 has T-SQL in it.
|
|
|
|
|
I'd say T-SQL has SQL92 in it since T-SQL is essentially a superset, but I know what you mean.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Fair point, it cuts both ways.
Would you call one or the other a superset in relation?
|
|
|
|
|
T-SQL is roughly a superset of SQL92
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Yeah that makes sense. I think in my head I lump T-SQL and PL/SQL together as DDL/DML.
|
|
|
|
|
jochance wrote: When you look for things, look for ANSI SQL.
Been doing DB for 40 years and that never came up.
First of course the goal is the enterprise solution and not the nuts and bolts. Architecture and design matter far more.
Most SQL is rather easy an mundane. And ANSI SQL works for that.
But more complex problems cannot be done at all in ANSI SQL. So attempting to limit oneself to that means ignoring features of the database that have been optimized over years or even decades to provide features like that. Versus silly things like attempt to figure out how to do it in a programming language rather than using the database itself.
Not to mention of course the real costs associated with licensing, maintenance and even the real cost of using existing knowledge of a technology versus attempting a new one.
So even if you can find a database that is not compliant, especially for most of the major parts, the consideration is just not worth the time.
|
|
|
|
|
For my part, as long as the database supports SQL92 as a baseline I'm willing to learn some of the DB specific features I need to be effective with it. I just intend to lean heavily on common SQL that works across DBs where I can.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: as long as the database supports SQL92
You would probably need to look really hard to find a SQL one that doesn't do that.
|
|
|
|
|
Yeah, but I just wanted to be clear, and also eliminate the possibility of any half arsed implementations.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
:cough: Cache :cough:
(Not fully SQL92 compliant. Worst is lack of order-of-operations.)
|
|
|
|
|
|
|
|
Doesn't say SQL-92 compliant, only that it has at least some features.
"
SQL-92 Compliance
The SQL-92 standard is imprecise with regard to arithmetical operator precedence; assumptions on this matter differ amongst SQL implementations. Caché SQL supports two system-wide alternatives for SQL arithmetic operator precedence:
By default, Caché SQL parses arithmetic expressions in strict left-to-right order, with no operator precedence. This is the same convention used in ObjectScript. Thus, 3+3*5=30. You can use parentheses to enforce the desired precedence. Thus, 3+(3*5)=18.
You can configure Caché SQL to parse arithmetic expressions using ANSI precedence, which gives higher precedence to multiplication and division operators than addition, subtraction, and concatenation operators. Thus, 3+3*5=18. You can use parentheses to override this precedence, where desired. Thus, (3+3)*5=30.
Caché SQL supports the complete entry-level SQL-92 standard with the following exceptions:
There is no support for adding additional CHECK constraints to a table definition.
The SERIALIZABLE isolation level is not supported.
Delimited identifiers are not case-sensitive; the standard says that they should be case-sensitive.
Within a subquery contained in a HAVING clause, one is supposed to be able to refer to aggregates which are “available” in that HAVING clause. This is not supported.
" -- Introduction to Caché SQL | Using Caché SQL | Caché & Ensemble 2018.1.4 – 2018.1.9[^]
|
|
|
|
|
It's the portability aspect.
Things went many directions at once.
Value outpaced usefulness.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
