Which RDBMS?
-
I come from a Microsoft background. I'm pretty good at managing SQL Server databases, making them parallel and fast, and I know T-SQL quite well. To a lesser degree I know SQL92 but I sometimes get T-SQL mixed into it. I'm trying to decide what RDBMS to run on my Debian VPS. Obviously it's not going to be SQL Server. I expect light traffic. I'm wondering if Postgre might be the best option (most familiar) for me? Or if it would be overkill as I only really need simple stuff for the most part. I don't think I'll need triggers or jobs, for example. Maybe I'd also be taking on too much management. I'd prefer it be something i can set up and forget about more or less. Mysql is another option and might be worth learning because it's so ubiquitous, but my main concern with it is overhead in terms of learning curve. My biggest priority is to reduce that curve. I don't want to spend time learning about a different RDBMS way of doing things wherever I can avoid it. I just don't want to invest the time. I'm not sure which one would be a good fit for my use cases, which are still open ended at this point, except light traffic and simple, smallish datasets. Like I said, by biggest priority is a flattish learning curve, so the closer I can get to MS SQL Server "feel" the happier I'll be. In the alternative, an RDBMS that's fairly automatic with few user facing moving parts outside of SQL/DDL/DML would be okay. I'm not sold on those two offerings either. If someone has a better idea, I'm all for trying it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
[Firebird](http://firebirdsql.org/). It is easy to go from embedded to a full RDBMS. [FirebirdFAQ.org - up-to-date answers to Firebird related questions](http://www.firebirdfaq.org/)
-
I come from a Microsoft background. I'm pretty good at managing SQL Server databases, making them parallel and fast, and I know T-SQL quite well. To a lesser degree I know SQL92 but I sometimes get T-SQL mixed into it. I'm trying to decide what RDBMS to run on my Debian VPS. Obviously it's not going to be SQL Server. I expect light traffic. I'm wondering if Postgre might be the best option (most familiar) for me? Or if it would be overkill as I only really need simple stuff for the most part. I don't think I'll need triggers or jobs, for example. Maybe I'd also be taking on too much management. I'd prefer it be something i can set up and forget about more or less. Mysql is another option and might be worth learning because it's so ubiquitous, but my main concern with it is overhead in terms of learning curve. My biggest priority is to reduce that curve. I don't want to spend time learning about a different RDBMS way of doing things wherever I can avoid it. I just don't want to invest the time. I'm not sure which one would be a good fit for my use cases, which are still open ended at this point, except light traffic and simple, smallish datasets. Like I said, by biggest priority is a flattish learning curve, so the closer I can get to MS SQL Server "feel" the happier I'll be. In the alternative, an RDBMS that's fairly automatic with few user facing moving parts outside of SQL/DDL/DML would be okay. I'm not sold on those two offerings either. If someone has a better idea, I'm all for trying it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
From what I know, MSSQL exists for Linux also. growing up with Multics, learning UNIX and then Linux for over 25 years, I abandoned that platform completely for Microsoft when I found that my peers had used Microsoft products and they were able to upgrade their solutions as time passed. I had to fight every time with Unix/Linux changes. After 15 years on the Microsoft path I have never looked back and I am going on 40 years of developing software and I can maintain and upgrade applications from even 20 years ago. Having software out there bringing you rent, the better off you are and the more time you have to develop. That learning curve is bad enough with new technology alone, so I advise you to stick with your tools. I wish you luck!
-
Interesting bit of trivia: Michael Widenius named MariaDB after his daughter, Maria. He had previously named MySQL after his son, My, and MaxDB after his son, Max. Michael Widenius - Wikipedia[^] I would personally recommend MariaDB over MySQL these days; I'm not a fan of the way Oracle have been handling MySQL. PostGreSQL is also an excellent choice of RDBMS for Linux platforms. <°}}}><
This is my son My?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
I come from a Microsoft background. I'm pretty good at managing SQL Server databases, making them parallel and fast, and I know T-SQL quite well. To a lesser degree I know SQL92 but I sometimes get T-SQL mixed into it. I'm trying to decide what RDBMS to run on my Debian VPS. Obviously it's not going to be SQL Server. I expect light traffic. I'm wondering if Postgre might be the best option (most familiar) for me? Or if it would be overkill as I only really need simple stuff for the most part. I don't think I'll need triggers or jobs, for example. Maybe I'd also be taking on too much management. I'd prefer it be something i can set up and forget about more or less. Mysql is another option and might be worth learning because it's so ubiquitous, but my main concern with it is overhead in terms of learning curve. My biggest priority is to reduce that curve. I don't want to spend time learning about a different RDBMS way of doing things wherever I can avoid it. I just don't want to invest the time. I'm not sure which one would be a good fit for my use cases, which are still open ended at this point, except light traffic and simple, smallish datasets. Like I said, by biggest priority is a flattish learning curve, so the closer I can get to MS SQL Server "feel" the happier I'll be. In the alternative, an RDBMS that's fairly automatic with few user facing moving parts outside of SQL/DDL/DML would be okay. I'm not sold on those two offerings either. If someone has a better idea, I'm all for trying it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I have administered a system for 9 years based on PostgreSQL, another system for 17 years based on SQL Server, and maintain a private Linux system based on MySQL. Of all the systems mentioned in this thread, PostgreSQL is my favorite for three main reasons: 1. It is free, unless you want to pay for support. 2. It is object oriented. Writing procedures that work together is very pleasant in PostgreSQL. 3. It is pure, not beset with encumbering licenses from corporations wanting to take over the world. 4. I can and have fairly easily written my own extension for it. In my case, it was my own version of SOUNDEX. For SQL Server: 1. It is not free. 2. When I write a View2 that uses a View1, if View1 is ever updated, View2 does not see the update until I ALTER (with no changes needed) View2. 3. I use the Microsoft OPENQUERY a lot to do joins on remote databases before the data is received on my end. One problem with it is that it does not accept variables of any sort. 4. The interface is generally polished and familiar to me. My main irritation is the line numbering used on error messages that don't match my source without doing arithmetic. For MySQL: 1. It is free up to a point. 2. It has ubiquitous documentation. 3. It is maintained poorly by Oracle, with whom I have had unpleasant communications with an arrogant salesman. 4. It has been patched to use multiple engines in an attempt to get wanted features. I.e., it is a bit of a mess. 5. I think I would rather use MariaDB, but haven't had the opportunity.
-
This is my son My?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
That would be daughter My: Little My[^]. I think the photo of that actress has very little resemblance to Little My in the books. There is a lot more truthful rendering at Little My hook[^]. Or just google for 'Little My' images, and you'll have dozens to choose from. (In the books, the drawings were made with an ink pen, black line only. I never knew that My always wore a red dress - that is something added by the marketing people for all the spin-off effects, to make her more visible. As if she wasn't visible enough already :-) And ... I really hate some of those spin offs! Especially the comics and animations - they were made by people who never grasped the spirit of the Moomins at all! If you have read the original books - which is highly recommended - the comics and animations are like a completely different world, only with characters looking the same and named the same. It isn't Moomin Valley!)
Religious freedom is the freedom to say that two plus two make five.
-
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
-
I have administered a system for 9 years based on PostgreSQL, another system for 17 years based on SQL Server, and maintain a private Linux system based on MySQL. Of all the systems mentioned in this thread, PostgreSQL is my favorite for three main reasons: 1. It is free, unless you want to pay for support. 2. It is object oriented. Writing procedures that work together is very pleasant in PostgreSQL. 3. It is pure, not beset with encumbering licenses from corporations wanting to take over the world. 4. I can and have fairly easily written my own extension for it. In my case, it was my own version of SOUNDEX. For SQL Server: 1. It is not free. 2. When I write a View2 that uses a View1, if View1 is ever updated, View2 does not see the update until I ALTER (with no changes needed) View2. 3. I use the Microsoft OPENQUERY a lot to do joins on remote databases before the data is received on my end. One problem with it is that it does not accept variables of any sort. 4. The interface is generally polished and familiar to me. My main irritation is the line numbering used on error messages that don't match my source without doing arithmetic. For MySQL: 1. It is free up to a point. 2. It has ubiquitous documentation. 3. It is maintained poorly by Oracle, with whom I have had unpleasant communications with an arrogant salesman. 4. It has been patched to use multiple engines in an attempt to get wanted features. I.e., it is a bit of a mess. 5. I think I would rather use MariaDB, but haven't had the opportunity.
Quote:
When I write a View2 that uses a View1, if View1 is ever updated, View2 does not see the update until I ALTER (with no changes needed) View2.
Do you mean if it is created without [schemabinding](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-view-transact-sql?view=sql-server-ver16#schemabinding)? Postgresql was different, there it was the default. Oh the joys of cascade dropping and recreating views and functions ... (Firebird 1.5 is the same) Oracle is [wise](https://forums.oracle.com/ords/apexds/post/schema-bound-view-9059) . Creating views on views therefore considered a bad practice.
-
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.
:cough: Cache :cough: (Not fully SQL92 compliant. Worst is lack of order-of-operations.)
-
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).
jochance wrote:
Oracle does 'sequences' and MSSQL has 'identity'.
SQL Server has sequences and everyone should use them. No one should ever use identities or other auto-numbers.
-
jochance wrote:
Oracle does 'sequences' and MSSQL has 'identity'.
SQL Server has sequences and everyone should use them. No one should ever use identities or other auto-numbers.
-
honey the codewitch wrote:
Mysql is another option and might be worth learning
There are two parts: Programming and Operations. For the first the vast majority between the major SQL databases are similar enough that one can get through it. There can be gotchas for things like the exact way one creates a stored proc but examples allow one to get through it. At least for me one problem with MySQL which I only just recently learned is that it has a history of 'losing' the seed indexes (auto increment). I can't state for certain how significant a problem it is in general but it seemed pretty significant to me that it happened at all. As for Operations I think you need to carefully consider your commitment to handling this for your users. Given your other posts maybe this must be a server only solution but I will say that the cloud solutions eliminate the vast majority of maintenance work and can be very low cost as long as one very carefully throttles everything.
-
Yeah they haven't been around forever on that side but I remember liking them on the other.
I liked sequences in Oracle enough to implement my own in SQL Server before they were built-in. " When were sequences added to SQL Server? The sequence object was introduced with the rollout of SQL Server 2012. "
-
I have administered a system for 9 years based on PostgreSQL, another system for 17 years based on SQL Server, and maintain a private Linux system based on MySQL. Of all the systems mentioned in this thread, PostgreSQL is my favorite for three main reasons: 1. It is free, unless you want to pay for support. 2. It is object oriented. Writing procedures that work together is very pleasant in PostgreSQL. 3. It is pure, not beset with encumbering licenses from corporations wanting to take over the world. 4. I can and have fairly easily written my own extension for it. In my case, it was my own version of SOUNDEX. For SQL Server: 1. It is not free. 2. When I write a View2 that uses a View1, if View1 is ever updated, View2 does not see the update until I ALTER (with no changes needed) View2. 3. I use the Microsoft OPENQUERY a lot to do joins on remote databases before the data is received on my end. One problem with it is that it does not accept variables of any sort. 4. The interface is generally polished and familiar to me. My main irritation is the line numbering used on error messages that don't match my source without doing arithmetic. For MySQL: 1. It is free up to a point. 2. It has ubiquitous documentation. 3. It is maintained poorly by Oracle, with whom I have had unpleasant communications with an arrogant salesman. 4. It has been patched to use multiple engines in an attempt to get wanted features. I.e., it is a bit of a mess. 5. I think I would rather use MariaDB, but haven't had the opportunity.
Bruce Patin wrote:
When I write a View2 that uses a View1, if View1 is ever updated, View2 does not see the update until I ALTER (with no changes needed) View2.
Seek ye the sp_refreshview procedure. Use it as needed. At my last job I implemented a procedure which ran it on all views in accordance with their dependencies. It was part of our standard prod deployment process.
-
I come from a Microsoft background. I'm pretty good at managing SQL Server databases, making them parallel and fast, and I know T-SQL quite well. To a lesser degree I know SQL92 but I sometimes get T-SQL mixed into it. I'm trying to decide what RDBMS to run on my Debian VPS. Obviously it's not going to be SQL Server. I expect light traffic. I'm wondering if Postgre might be the best option (most familiar) for me? Or if it would be overkill as I only really need simple stuff for the most part. I don't think I'll need triggers or jobs, for example. Maybe I'd also be taking on too much management. I'd prefer it be something i can set up and forget about more or less. Mysql is another option and might be worth learning because it's so ubiquitous, but my main concern with it is overhead in terms of learning curve. My biggest priority is to reduce that curve. I don't want to spend time learning about a different RDBMS way of doing things wherever I can avoid it. I just don't want to invest the time. I'm not sure which one would be a good fit for my use cases, which are still open ended at this point, except light traffic and simple, smallish datasets. Like I said, by biggest priority is a flattish learning curve, so the closer I can get to MS SQL Server "feel" the happier I'll be. In the alternative, an RDBMS that's fairly automatic with few user facing moving parts outside of SQL/DDL/DML would be okay. I'm not sold on those two offerings either. If someone has a better idea, I'm all for trying it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Support them all and allow the user to choose what he wants. :)
-
Bruce Patin wrote:
When I write a View2 that uses a View1, if View1 is ever updated, View2 does not see the update until I ALTER (with no changes needed) View2.
Seek ye the sp_refreshview procedure. Use it as needed. At my last job I implemented a procedure which ran it on all views in accordance with their dependencies. It was part of our standard prod deployment process.
Thanks for the info!
-
Quote:
When I write a View2 that uses a View1, if View1 is ever updated, View2 does not see the update until I ALTER (with no changes needed) View2.
Do you mean if it is created without [schemabinding](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-view-transact-sql?view=sql-server-ver16#schemabinding)? Postgresql was different, there it was the default. Oh the joys of cascade dropping and recreating views and functions ... (Firebird 1.5 is the same) Oracle is [wise](https://forums.oracle.com/ords/apexds/post/schema-bound-view-9059) . Creating views on views therefore considered a bad practice.
I try to avoid views of a view, but it fit my desire for DRY (Don't Repeat Yourself) and laziness. :)
-
This is my son My?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
Sorry: I'd misremembered. My is his daughter. I'd always lazily assumed that it was part of the M$-led trend to call everything "my something-or-other": My Documents, My Videos, My SQL - it made sense. It was quite delicious to discover the truth. <°}}}>«<
-
:cough: Cache :cough: (Not fully SQL92 compliant. Worst is lack of order-of-operations.)
PIEBALDconsult wrote:
cough: Cache :cough:
Never heard of it. Not possible to google it with that name either. I don't see it on the following list. And noting that list has a lot of no-SQL solutions and even solutions that are stretching the definition of database. DB-Engines Ranking - popularity ranking of database management systems[^]