|
Replies:
56
-
Last Post:
Apr 11, 2016 12:46 PM
Last Post By: John Kaster
|
|
|
Posts:
590
Registered:
12/1/99
|
|
|
|
Posts:
2,414
Registered:
9/22/99
|
|
Mike Margerum wrote:
Idera better get crackin hehe
Wow.
--
Nick
Delphi Programming is Fun |
|
|
|
|
Posts:
196
Registered:
12/10/99
|
|
On 3/7/2016 16:00, Mike Margerum wrote:
I think it's safe to say that hell is undergoing global cooling at this
point. |
|
|
|
|
Posts:
397
Registered:
10/10/99
|
|
On 8/03/2016 8:00 AM, Mike Margerum wrote:
Pointless, SQL Sever is just too expensive, costing way more than
windows, and the cost of windows is one of the main reasons people want
to switch to linux. I can't see them making the linux version any
cheaper. I'd go with postgres rather than sql server any day.
--
Regards
Vincent Parrett
CEO - VSoft Technologies Pty Ltd
https://www.finalbuilder.com
Blog: https://www.finalbuilder.com/resources/blogs
Automate your Software builds with FinalBuilder.
Open Source : https://github.com/VSoftTechnologies |
|
|
|
|
Posts:
19
Registered:
5/7/97
|
|
In article <822113 at forums dot embarcadero dot com>, Vincent Parrett wrote:
Pointless, SQL Sever is just too expensive, costing way more than
windows, and the cost of windows is one of the main reasons people want
to switch to linux. I can't see them making the linux version any
cheaper. I'd go with postgres rather than sql server any day.
If you can live with a 10gb limit on the database size, SQL Server Express
is free.
http://www.microsoft.com/en-us/server-cloud/products/sql-server-editions/s
ql-server-express.aspx
Steve Tyrakowski |
|
|
|
|
Posts:
590
Registered:
12/1/99
|
|
On 3/7/16 4:38 PM, Vincent Parrett wrote:
On 8/03/2016 8:00 AM, Mike Margerum wrote:
Pointless, SQL Sever is just too expensive, costing way more than
windows, and the cost of windows is one of the main reasons people want
to switch to linux. I can't see them making the linux version any
cheaper. I'd go with postgres rather than sql server any day.
SQL Server standard edition is quite inexpensive IMO for what you get.
They may not make the Linux version cheaper, but the licensing for a
Linux server instance can be cheaper than a windows server product. The
only reason I even use a windows server at this point is to host SQL
Server. I've been using SQL server since 6.5 and its a fantastic product. |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
Mike Margerum wrote:
SQL Server standard edition is quite inexpensive IMO for what you
get. They may not make the Linux version cheaper, but the licensing
for a Linux server instance can be cheaper than a windows server
product. The only reason I even use a windows server at this point
is to host SQL Server. I've been using SQL server since 6.5 and
its a fantastic product.
A lot of people just use MySQL and ignore the licence - that makes
MSSQL 'seem' expensive.
Until you start pricing MySQL for commercial + non LAMP/WAMP usage. |
|
|
|
|
Posts:
913
Registered:
9/22/99
|
|
Christopher Burke wrote:
A lot of people just use MySQL and ignore the licence - that makes
MSSQL 'seem' expensive.
MariaDB, Percona, and PostgreSQL all have biz-friendly licenses.
--
John Kaster http://johnkaster.wordpress.com
Software solutions |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
John Kaster wrote:
Christopher Burke wrote:
A lot of people just use MySQL and ignore the licence - that makes
MSSQL 'seem' expensive.
MariaDB, Percona, and PostgreSQL all have biz-friendly licenses.
As does MSSQL  |
|
|
|
|
Posts:
23
Registered:
9/27/00
|
|
On 06.04.2016 07:26, Christopher Burke wrote:
John Kaster wrote:
Christopher Burke wrote:
A lot of people just use MySQL and ignore the licence - that makes
MSSQL 'seem' expensive.
MariaDB, Percona, and PostgreSQL all have biz-friendly licenses.
As does MSSQL
As does Firebird.
--
Aage J. |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
Aage Johansen wrote:
On 06.04.2016 07:26, Christopher Burke wrote:
John Kaster wrote:
Christopher Burke wrote:
A lot of people just use MySQL and ignore the licence - that makes
MSSQL 'seem' expensive.
MariaDB, Percona, and PostgreSQL all have biz-friendly licenses.
As does MSSQL
As does Firebird.
We are moving away from Firebird, too many issues. |
|
|
|
|
Posts:
23
Registered:
9/27/00
|
|
On 07.04.2016 14:48, Christopher Burke wrote:
Aage Johansen wrote:
On 06.04.2016 07:26, Christopher Burke wrote:
John Kaster wrote:
Christopher Burke wrote:
A lot of people just use MySQL and ignore the licence - that makes
MSSQL 'seem' expensive.
MariaDB, Percona, and PostgreSQL all have biz-friendly licenses.
As does MSSQL
As does Firebird.
We are moving away from Firebird, too many issues.
What kind of issues? Bugs/errors, missing features or something else?
--
Aage J. |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
Aage Johansen wrote:
What kind of issues? Bugs/errors, missing features or something
else?
SQL standards non-compliance, errors and a server connection issues.
The only thing it seems to have going for it is speed.
We went through all the decisions around 4-5 years ago - so I can't be
too specific now, and it may have got better.
However - MSSQL is free for our needs, and rock solid. |
|
|
|
|
Posts:
23
Registered:
9/27/00
|
|
On 07.04.2016 17:00, Christopher Burke wrote:
Aage Johansen wrote:
What kind of issues? Bugs/errors, missing features or something
else?
SQL standards non-compliance, errors and a server connection issues.
The only thing it seems to have going for it is speed.
We went through all the decisions around 4-5 years ago - so I can't be
too specific now, and it may have got better.
However - MSSQL is free for our needs, and rock solid.
Thanks for your comments. I would have thought that if SQL standards
compliance was important, then MSSQL isn't the best choice.
Anyway, after using Firebird for more than 15 years I still like it a lot.
--
Aage J. |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
Aage Johansen wrote:
Thanks for your comments. I would have thought that if SQL
standards compliance was important, then MSSQL isn't the best choice.
It wasn't that important until we ran into problems with Firebase |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 07.04.2016 um 23:27 schrieb Christopher Burke:
Aage Johansen wrote:
Thanks for your comments. I would have thought that if SQL
standards compliance was important, then MSSQL isn't the best choice.
It wasn't that important until we ran into problems with Firebase
Firebase or Firebird?
And which version?
Greetings
Markus |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
Markus Humm wrote:
Am 07.04.2016 um 23:27 schrieb Christopher Burke:
Aage Johansen wrote:
Thanks for your comments. I would have thought that if SQL
standards compliance was important, then MSSQL isn't the best
choice.
It wasn't that important until we ran into problems with Firebase
Firebase or Firebird?
Firebird sorry, mix it up with Interbase too often.
We made the switch in around 2012, so what ever was the newest version
then. |
|
|
|
|
Posts:
913
Registered:
9/22/99
|
|
Christopher Burke wrote:
As does MSSQL
I was restricting my list to free licenses that are not viral.
--
John Kaster http://johnkaster.wordpress.com
Software solutions |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
John Kaster wrote:
Christopher Burke wrote:
As does MSSQL
I was restricting my list to free licenses that are not viral.
MSSQL is free licence, no virus found when I scan it |
|
|
|
|
Posts:
913
Registered:
9/22/99
|
|
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
Vincent Parrett wrote:
Pointless, SQL Sever is just too expensive, costing way more than
windows, and the cost of windows is one of the main reasons people
want to switch to linux. I can't see them making the linux version
any cheaper. I'd go with postgres rather than sql server any day.
We use SQL Server for our clients because MSSQL server for FREE is
cheaper than $2000 or so for MySQL. |
|
|
|
|
Posts:
143
Registered:
2/17/02
|
|
We use SQL Server for our clients because MSSQL server for FREE is
cheaper than $2000 or so for MySQL.
PostgreSQL is free and cross-platform, and has unique features and abilities.
You could start from a small local DB up to a full replicated farm of servers.
Take a look at the latest releases... worth investigating... performance has been enhanced a lot, replication has been made much easier to work with, and some features are just amazing, like JSONB. |
|
|
|
|
Posts:
143
Registered:
2/17/02
|
|
PostgreSQL is free and cross-platform, and has unique features and abilities.
You may also consider FireBird, if you want something cross-platform and Open Source - which may fit better with a Delphi / Interbase background...
On our side, we build a farm of mORMot SOA servers using their own local high-performance in-process SQlite3 databases, then remote MongoDB or PostgreSQL storage for gathered/centralized information.
Such an Event Driven / Event Sourcing architecture scales in an amazing way.
See http://martinfowler.com/eaaDev/EventSourcing.html
With low hosting cost, and no license issue, as with MS SQL. |
|
|
|
|
Posts:
337
Registered:
1/25/98
|
|
|
Personally, I like to go with ElevateSoftware's ElevateDB, which is all
Delphi, well supported, and has lots of facilities. The fact it can be
embedded in my code makes it quite reliable. While I've used MySQL and
SQLServer, they always seem that little bit more complex than I really
need, whereas EDB is capable enough and not over-complex. (It does have
things like replication, but I shy away from such things!)
|
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
embedded in my code makes it quite reliable. While I've used MySQL and
In a data-centric approach, and most large, critical DBs are data-centric, data stored are much more valuable than the application(s) accessing them - while applications and technologies come and go, data stays for a far longer time.
Moreover the same data, could be used by many different applications, and you usually want to avoid to have to duplicate them in many different stores and keep them in sync - usually it means they become incoherent quickly and lead to troubles (including management ones - backups, etc.). Also, separated silos hinder the sharing of precious data inside a company.
Thereby you want to avoid anything that strongly ties the data to the application which creates them - and you want to be able to access them from any application that may need that data. You also want most of the data logic (including the security logic) inside the database, to ensure it is consistent end enforced across different applications and users (you can move it in another middle tier only if that tier is the only way to access the data).
That's why some people need to use database like SQL Server or Oracle.... |
|
|
|
|
Posts:
337
Registered:
1/25/98
|
|
Luigi Sandon wrote:
Thereby you want to avoid anything that strongly ties the data to the
application which creates them
It is a good point, and as with all things, sometimes you want the
opposite. One for the designer to ponder... |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Matthew Jones wrote:
Luigi Sandon wrote:
Thereby you want to avoid anything that strongly ties the data to
the application which creates them
It is a good point, and as with all things, sometimes you want the
opposite. One for the designer to ponder...
I guess it depends on what kind of software you develop: in-house,
shrink-wrap, etc.etc.
--
Rudy Velthuis http://www.rvelthuis.de
"If god created us in his image we have certainly returned the
compliment."
-- Voltaire |
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
I guess it depends on what kind of software you develop: in-house,
shrink-wrap, etc.etc.
IMHO it depends more on what data you store and why (that's why I specified "in a data centric approach").
For example, take Lightroom. Most of the data it stores in its DB have a meaning only insight Lightroom itself - well, EXIF and IPCT data have a meaning outside it, but "develop" settings and so on have a meaning only for Lightroom own algorithms. Thereby I have little issues if it comes with its own database - proprietary or not (it uses SQLite, though) - but probably as long as it is mostly a single-user stand-alone application.
If I were part of a photo studio/agency, and different people need to work on the images using different tools along the workflow - from creation to publishing (and invoicing) - I would like tools that are able to work on the same database to minimize the risk of duplicated (and probably out of sync) data, missing/lost data, etc. etc.
If I were a dentist :-P, I'd like that the applications storing medical records shares easily some of the data with the invoicing ones (I know most of the times they are the same app, or part of the same product suite...), to minimize the risks of "corrupted" data because of the need to sync/replicate them. And in this case, IMHO the medical records are more important than the application accessing them - they can be useful and important for a lot of years - so having a well supported, clearly defined (and documented) database is important, especially if the product used today may be no longer be available tomorrow.
In other situations, for example a very vertical system storing data for its consumption alone, and where you're interested only in its final outputs, can store its data whatever it likes.
I understand some developers may like some form of customer lock-in - but it's a double edged sword, someone may not buy your product exactly for the lock-in reason. IMHO customers should keep on buying your product because it's among the best around, not because they can no longer escape... |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Luigi Sandon wrote:
I guess it depends on what kind of software you develop: in-house,
shrink-wrap, etc.etc.
IMHO it depends more on what data you store and why (that's why I
specified "in a data centric approach").
And that greatly depends on the kind of sofware you develop.
--
Rudy Velthuis http://www.rvelthuis.de
"I was asked to memorize what I did not understand; and, my
memory being so good, it refused to be insulted in that
manner."
-- Aleister Crowley |
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
And that greatly depends on the kind of sofware you develop.
Yes, kind of software, but not much on how you develop or sell it. I've seen companies developing in-house and each department using their different tools and databases - often it led to a lot of duplicated, out of sync data and big headaches to use them at the company advantage - situation where X doesn't know Y already has the data it needs. I found that if someone has a comprehensive view of the company's data, there are better chance development efforts, in-house or external, are focused in taking advantages of "cooperation" and avoid unnecessary segregated "silos".
If you sell COTS software you should assess your target market and understand what is the best way to serve it - integrating with existing products or instead go your full own way, I've seen too many "migration efforts" because a company wants to consolidate its data (especially for some "big data" analytics, today), and has to deduplicate and sync all the different silos used by different applications it owns. Today, often the value is in the data, not only in the data management. In paper times it was difficult to consolidate data because concurrent access was an issue, and that kept on being an issue when IT systems were not connected, or through too slow links (you may still want to "mirror" data for safety reasons - just you keep them in sync).
Data mining, BI, Big Data, call it whatever you like, require a good starting dataset to be effective. Data fragmentation usually doesn't help - after all even "cloud storage" is a way to have a central storage instead of many fragmented silos with just a subset of information, and probably the common one not properly synced. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Luigi Sandon wrote:
And that greatly depends on the kind of sofware you develop.
Yes, kind of software, but not much on how you develop or sell it.
Of course it does. Shrink-wrap software has considerably different
needs from an in-house app, or, say, a game.
--
Rudy Velthuis http://www.rvelthuis.de
"Tooth decay was a perennial national problem that meant a
mouthful of silver for patients, and for dentists a pocketful
of gold." -- Claudia Wallis |
|
|
|
|
Posts:
414
Registered:
6/2/98
|
|
I guess it depends on what kind of software you develop: in-house,
shrink-wrap, etc.etc.
Or what the customer wants. Most businesses already have the expertise in-house to maintain (backup- restore,migrate) MSSQL or Oracle.
|
|
|
|
|
Posts:
248
Registered:
1/12/00
|
|
On Wed, 6 Apr 2016 02:55:53 -0700, Luigi Sandon <> wrote:
In a data-centric approach, and most large, critical DBs are data-centric, data stored are much more valuable than the application(s) accessing them - while applications and technologies come and go, data stays for a far longer time.
Moreover the same data, could be used by many different applications, and you usually want to avoid to have to duplicate them in many different stores and keep them in sync - usually it means they become incoherent quickly and lead to troubles (including management ones - backups, etc.). Also, separated silos hinder the sharing of precious data inside a company.
Thereby you want to avoid anything that strongly ties the data to the application which creates them - and you want to be able to access them from any application that may need that data. You also want most of the data logic (including the security logic) inside the database, to ensure it is consistent end enforced across different applications and users (you can move it in another middle tier only if that tier is the only way to access the data).
besides the above mentioned reasons often the most efficient way to handle/process the data is to perform it as close to the data as
possible i.e. right within database/server backend that is specifically designed for such tasks instead of fetching the data from db to
another tier to process it there and push processed results back to db. of course that isn't always the case and that depends on the task
--
Vladimir Ulchenko aka vavan |
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
Pointless, SQL Sever is just too expensive, costing way more than
Too expensive for what and who? The cash-strapped little company storing a few GBs of data? The developer using a database like a simple data dump for a single web application?
There are reasons why "expensive" databases like Oracle, DB2 or SQL Server are running most critical databases, and others don't. Because they are designed to handle loads and situations others can't simply cope with. Then you have to factor in many other costs which are not those of the OS and the DB engine only.
Enjoy, for example, partitioning with Postgres... |
|
|
|
|
Posts:
590
Registered:
12/1/99
|
|
On 4/6/16 5:25 AM, Luigi Sandon wrote:
Pointless, SQL Sever is just too expensive, costing way more than
SQL Server Standard edition is stupidly cheap for what you get. |
|
|
|
|
Posts:
92
Registered:
5/8/08
|
|
SQL Server Standard edition is stupidly cheap for what you get.
Don't know what you consider stupidly cheap. I think it's reasonable but would not call it cheap - core licensing is $2K per core. For quad core cpu the buy-in is $8K. Enterprise for same would be 3-4 times more. One could go with server license + CALs but license agreement makes it very complex to deploy outside organization (i.e. even something as simple as customer facing site using sql is major pain with this model).
Raul |
|
|
|
|
Posts:
590
Registered:
12/1/99
|
|
On 4/6/16 1:31 PM, Raul Sinimae wrote:
SQL Server Standard edition is stupidly cheap for what you get.
Don't know what you consider stupidly cheap. I think it's reasonable but would not call it cheap - core licensing is $2K per core. For quad core cpu the buy-in is $8K. Enterprise for same would be 3-4 times more. One could go with server license + CALs but license agreement makes it very complex to deploy outside organization (i.e. even something as simple as customer facing site using sql is major pain with this model).
Raul
$8k for even an SMB for something that will run your business for years
is a no brainier. If $8k is an issue, then you are running a lemonade
stand or you are prioritizing your costs wrong IMO.
Now if you resell software or need a lot of instances of a DB then SQL
Server may not be as good a deal. |
|
|
|
|
Posts:
92
Registered:
5/8/08
|
|
$8k for even an SMB for something that will run your business for years
is a no brainier. If $8k is an issue, then you are running a lemonade
stand or you are prioritizing your costs wrong IMO.
Simply saying that it can be a non trivial amount these days.
Even with products we're using ourselves i'm seeing increased presence of PostgreSQL as a DB option now.
Raul |
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
Even with products we're using ourselves i'm seeing increased presence of PostgreSQL as a DB option now.
Believe me, if you're selecting Postgres (or any other tool) just because it is "free" you're doing the wrong choice. As I often said about Delphi, what matters is not the "price" alone, it's the "price/feature" ratio that matters. If you assessed Postgres and it fulfills your need fully, and you have not to pay for it, the better. If you didn't assess it properly, and then find yourself in a nightmare because you find it miss or doesn't implement properly what you need, you may end up to spend more to add them somehow, and maintain them.
For example, Postgres doesn't support still transaparent and automatic partitioning. If you need it, you need to write and maintain triggers, etc. to make it working, Did you assessed your partitioning need correctly? Or you may find later you really need it, but made the wrong choice?
Another example SQL Server is fully integrated with Windows, for example Active Directory, This feature can simplify management and increase security a lot. If you need it, it can save a lot of implementation efforts and headaches. If you don't, it's just wasted money.
You need to look at the overall picture, and how much you're going to spend overall. |
|
|
|
|
Posts:
92
Registered:
5/8/08
|
|
You need to look at the overall picture, and how much you're going to spend overall.
I fully agree with you but I was referring to products we're using ourselves (i.e. we're the customer in this case) - 2 of them for example are offering it as an optional back-end DB option (in addition to MS-SQL).
Raul |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
Mike Margerum wrote:
$8k for even an SMB for something that will run your business for
years is a no brainier. If $8k is an issue, then you are running a
lemonade stand or you are prioritizing your costs wrong IMO.
Or maybe you don't know all the possibilities.
$8 would DOUBLE the cost to us for many of our clients - and that's
double including hardware and software.
For our business, the cost would be of the order of $800k - $1 million
at $8k per server. |
|
|
|
|
Posts:
590
Registered:
12/1/99
|
|
Or maybe you don't know all the possibilities.
$8 would DOUBLE the cost to us for many of our clients - and that's
double including hardware and software.
For our business, the cost would be of the order of $800k - $1 million
at $8k per server.
I clearly stated that if you resold software it may not be a good fit. 
Postgres is a fine DB and if i needed more than a few licenses to SQL
Server standard it would be worth pursuing it. |
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
$8 would DOUBLE the cost to us for many of our clients - and that's
double including hardware and software.
For our business, the cost would be of the order of $800k - $1 million
at $8k per server.
The problem IMHO is the old habit to sell a RDBMS with every given application. We almost never did it (one exception was a wholly self-contained security monitoring system using Oracle Embedded, but it had to be a fully separate data storage for obvious reasons, and it was deployed as a big "appliance").
What databases are supported and the requirements are in the software documentation, then it's up to the customer to decide what it wants to use, and to provide it. It may reuse an existing one, or get a separate one, not an issue of ours. We could give an advice, depending if the customer is a full MS shop, or uses Linux servers, and so on.
Usually many already have database servers that can host the application data, thereby no added costs. Usually administrators like the option to avoid another server/instance to maintain/tune/backup if they can, unless they decide so because they think it's better for their requirements, not because it's forced by us. And they like the option to use databases they are comfortable with, and for which they have already tools for monitoring/maintenance/backup instead of being force to add another one they don't know, and lack the tools/expertise.
Anyway, if you need very large deployments for single applications you can usually find some good discounts. For example Oracle Embedded had (it was some years ago, don't know actual licenses terms) specific usage limitations (but not data size), but it came at a fairly reduced price compared to the plain versions. |
|
|
|
|
Posts:
267
Registered:
11/12/12
|
|
The problem IMHO is the old habit to sell a RDBMS with every given application. [...]
What databases are supported and the requirements are in the software documentation, then it's up to the customer to decide what it wants to use, and to provide it.
How do you handle schema updates when upgrading the application?
How do you ensure any SQL written works as expected across all supported DB's?
How do you deal with performance optimizations such as materialized views and similar?
We currently provide the DB for our application as well (Sybase SQL Anywhere), but some of our customers have asked for us to use their MSSQL or Oracle DB servers.
I'm not that experienced in the DB world, so I'm curious how to properly support multiple DBs.
Cheers
- Asbjørn |
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
How do you handle schema updates when upgrading the application?
We have a utility the DBA has to use - if the DBA requires it, we can also provide the SQL scripts themselves - sometimes some integration tasks require collaboration from the DBA to access already existing data properly.
Usually, we have no DBA access to the server, nor know any of the password used to maintain any schema/database. The database objects owner itself is never used to run the application - user accounts with proper privileges are used to minimize the attack surface. Whenever possible, we avoid using password altogether, and rely on better authentication mechanism.
How do you ensure any SQL written works as expected across all supported DB's?
That's a matter of automated testing - supporting multiple DBs increase complexity enough you can't do without.
Whenever possible, we move "data" logic to the DB and provide a DB API to the application.
How do you deal with performance optimizations such as materialized views and similar?
See above. Anyway, handling OLTP and DW type of databases usually requires a different approach - the latter may require far more specific optimizations.
I'm not that experienced in the DB world, so I'm curious how to properly support multiple DBs.
It's not a simple task, it requires a good design and a deep knowledge of the different databases supported and how to make access the more transparent you can to the upper layers of an application. You can't really use the "data aware" model of Delphi - it's too outdated today, and even then it was a too thin layer over the database clients and their physical management of data. MIDAS (Datasnap) looked promising in Delphi 3, but they borked it. There are other solutions, though.
I understand supporting a single database and delivering it with the application is simpler, yet it may mean to make deployment, management and data sharing far more complex for the customer. The depends on the customer also - if it doesn't have its own DBAs (full or part-time), all the maintenance is up to you and sharing data is not an option or not needed (for any truly good reason),, then a application-dedicated DB may be the right solution. |
|
|
|
|
Posts:
248
Registered:
1/12/00
|
|
On Mon, 11 Apr 2016 07:35:53 -0700, Luigi Sandon <> wrote:
I'm not that experienced in the DB world, so I'm curious how to properly support multiple DBs.
It's not a simple task, it requires a good design and a deep knowledge of the different databases supported and how to make access the more transparent you can to the upper layers of an application. You can't really use the "data aware" model of Delphi - it's too outdated today, and even then it was a too thin layer over the database clients and their physical management of data. MIDAS (Datasnap) looked promising in Delphi 3, but they borked it. There are other solutions, though.
I've been utilizing classic midas since 1999 and personally migrated few projects from mssql to oracle by facelifting of application servers
and sometimes switching to another dac there but client side apps based on cds and data aware controls never really required modifications
it's not always trivial but with the help of modern universal dacs abstracting backend peculiarities at least to some extent often it is
quite achievable
--
Vladimir Ulchenko aka vavan |
|
|
|
|
Posts:
267
Registered:
11/12/12
|
|
How do you handle schema updates when upgrading the application?
We have a utility the DBA has to use - if the DBA requires it, we can also provide the SQL scripts themselves - sometimes some integration tasks require collaboration from the DBA to access already existing data properly.
We also have a tool to upgrade the DB schema, I was thinking more about how you ensure that the change is compatible across all DBs. For example, if I write some new feature which requires storing some additional data in table, would I need to know the details about all the supported DBs to add the new columns to ensure I don't rely on something unsupported?
I'm not that experienced in the DB world, so I'm curious how to properly support multiple DBs.
It's not a simple task, it requires a good design and a deep knowledge of the different databases supported and how to make access the more transparent you can to the upper layers of an application. You can't really use the "data aware" model of Delphi - it's too outdated today, and even then it was a too thin layer over the database clients and their physical management of data. MIDAS (Datasnap) looked promising in Delphi 3, but they borked it. There are other solutions, though.
For us the biggest issue is that the program has 10+ years of legacy code, with varying code quality and such.
I understand supporting a single database and delivering it with the application is simpler, yet it may mean to make deployment, management and data sharing far more complex for the customer.
The vast majority of our customers don't really care about servers and such, they just want things to work. So the majority are happy to just give us a VM (frequently outsourced) and we install our DB and other server components there and handle support of "our stuff" (DB included). On the other hand we have some larger customers which would prefer for us to user their DB server, for many of the reasons you mentioned.
Data sharing is an issue though, especially for smaller customers who don't want to spend a lot of money on a custom solution.
Anyway, thanks for the detailed reply, much appreciated!
Cheers
- Asbjørn |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Raul Sinimae wrote:
SQL Server Standard edition is stupidly cheap for what you get.
Don't know what you consider stupidly cheap. I think it's reasonable
but would not call it cheap - core licensing is $2K per core.
I looked at several offers. Some sell it at less than $1000, and there
is no mention anywhere of the number of CPU cores.
--
Rudy Velthuis http://www.rvelthuis.de
"Every normal man must be tempted at times to spit upon his
hands, hoist the black flag, and begin slitting throats."
-- Henry Louis Mencken (1880-1956) |
|
|
|
|
Posts:
92
Registered:
5/8/08
|
|
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
I am flabbergasted. Actually, I am aghast. That's ridiculous.
Welcome to the realm of enterprise licensing... and that's not the most ridiculous one... |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Luigi Sandon wrote:
I am flabbergasted. Actually, I am aghast. That's ridiculous.
Welcome to the realm of enterprise licensing... and that's not the
most ridiculous one...
I shelled out more than 35k Euro for the new software+hardware in my
clinic, but nothing restricted me to a number of cores or even a number
of computers. Sheesh.
--
Rudy Velthuis http://www.rvelthuis.de
"Don't join the book burners."
-- Dwight D. Eisenhower |
|
|
|
|
Posts:
590
Registered:
12/1/99
|
|
On 4/7/16 10:59 AM, Raul Sinimae wrote:
Honestly, even if you are forking out $20,000 for a DB server that will
run your business for 5-8 years, you are talking about less than $4,000
a year. In the U.S., this is peanuts.
I'll concede there are plenty of scenarios where the costs start to
explode and Postgres might be a better option. It's pretty clear too
that m$ keeps reworking their licensing to extract more money out of
their clients.
All I know is i've been using SQL Server for 10 years on this project
that has millions of rows in some of the tables and it's never crashed
or lost a byte of data. It just works and it's fast. |
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
It's pretty clear too
that m$ keeps reworking their licensing to extract more money out of
their clients.
Just like €mbarcad€ro does.... <G> |
|
|
|
|
Posts:
590
Registered:
12/1/99
|
|
On 4/8/16 8:29 AM, Luigi Sandon wrote:
It's pretty clear too
that m$ keeps reworking their licensing to extract more money out of
their clients.
Just like €mbarcad€ro does.... <G>
Sure seems that way.
I had the Pro SKU for years. A few years back, I decided to go all in
with Delphi and buy the enterprise SKU because I was going to use
FireMonkey, FireDac, and DataSnap. Tried them all and decided not to
use any of them for lots of reasons. At this point, everything I need
is probably in the Pro SKU.
I'm just building VCL HTTP client apps that talk to my Go API server at
this point. Delphi is an excellent tool for building a thick windows
clients talking to REST API. Fast, nice looking with great reporting
and the TMS Excel component is awesome.
TMS' components and FastReports are the only other dependencies I have. |
|
|
|
|
Posts:
580
Registered:
9/25/99
|
|
Mike Margerum wrote:
On 4/6/16 5:25 AM, Luigi Sandon wrote:
Pointless, SQL Sever is just too expensive, costing way more than
SQL Server Standard edition is stupidly cheap for what you get.
Express edition is stupidly cheap for what you get |
|
|
|
|
Posts:
590
Registered:
12/1/99
|
|
SQL Server Standard edition is stupidly cheap for what you get.
Express edition is stupidly cheap for what you get
I started with that and it worked great. Once I outgrew it, i moved to
the full product. Brilliant of m$ to give you the first crack hit for
free hehe |
|
|
|
Legend
|
|
Helpful Answer
(5 pts)
|
|
Correct Answer
(10 pts)
|
|
Connect with Us