3 ms·

Aside from the cost aspect of commercial software, this is false. It is no more difficult to feed your data to another system than it is with any other relation

Aside from the cost aspect of commercial software, this is false. It is no more difficult to feed your data to another system than it is with any other relational databases. There is certainly no bill involved with exporting your data. In fact, SQL Server includes the tools you need to do this with software like SQL Server Integration Services. SQL Server has its own implementation of the ANSI SQL standard but this is true of every database system. The majority of it is compatible, it's only when you use certain functions that you have to consider porting them. SQL Server is the database used for many customer facing applications and there is often no nightmare involved.

brightball 10y ago
With a PostgreSQL foreign data wrapper, you can actively push data into other data sources at the transactional level. You have pub sub functionality built in to let outside systems listen and react to data changes as well. With SQL Server your options are variations of polling the database. We even tried posing the question of utilizing Elastic Search to developers at the PASS Summit recently and were widely met with groans of "Yea...that's a pain to do with SQL Server. You're basically out of luck." For an internal standalone system it's great. For moving data into it do do analytics, great. For anything close to a real time web facing system with a growth pattern...absolute nightmare.
- gaius 10y ago
  polling the database Not true https://msdn.microsoft.com/en-us/library/t9x04ed2(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/t9x04ed2(v=vs.110)....
- treebeard901 10y ago
  This is an impressive attempt to backup the original statements about SQL Server. It sounds like you may not be all that familiar with how the "Foreign Data Wrappers" work in Postgres and you are not familiar with the equivalent in SQL Server: Linked servers. Both implementations use OLEDB or ODBC drivers to provide transactional consistency to external applications.

brightball 10y ago

With a PostgreSQL foreign data wrapper, you can actively push data into other data sources at the transactional level. You have pub sub functionality built in to let outside systems listen and react to data changes as well. With SQL Server your options are variations of polling the database. We even tried posing the question of utilizing Elastic Search to developers at the PASS Summit recently and were widely met with groans of "Yea...that's a pain to do with SQL Server. You're basically out of luck." For an internal standalone system it's great. For moving data into it do do analytics, great. For anything close to a real time web facing system with a growth pattern...absolute nightmare.

gaius 10y ago
polling the database Not true https://msdn.microsoft.com/en-us/library/t9x04ed2(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/t9x04ed2(v=vs.110)....
treebeard901 10y ago
This is an impressive attempt to backup the original statements about SQL Server. It sounds like you may not be all that familiar with how the "Foreign Data Wrappers" work in Postgres and you are not familiar with the equivalent in SQL Server: Linked servers. Both implementations use OLEDB or ODBC drivers to provide transactional consistency to external applications.