Out of all the tools in the complete SQL Server package, I'm mainly using Toolbox and SQL Profiler because I'm using SSIS packets, so we're using job scheduling a lot. And sometimes we are creating the SSIS packages, so I'm using SQL Server for MSD for maintenance purposes. SQL Server is quite user-friendly. I have experience with Oracle and PostgreSQL, so out of three, I like SQL Server a lot.
They could increase the intelligence of SQL Server. That would be good for us. There are some good intelligent features in SQL Server. However, they need to increase the intelligence because people switching to SQL Server from other solutions are not so familiar with it. I've been working with SQL Server for the last six years, but people are coming from MySQL or Oracle, so it will take one or two months to adjust. Still, they could add some intelligent tools to convert Oracle into SQL Server something like that.
And sometimes when I'm writing a function, there is already a predefined structure available. So if they defined their structure more precisely, that would be good for us. And the last thing I would like to add is that SQL Server should handle queries more like Oracle does. For example, you submit a query in Oracle, and the whole table comes up. In SQL Server, you go to the table, right-click, and it lets you see the first 200 rows. Then on top of that, you can add 200 more rows.
So in place of those 200 rows, if I can update all my table records or search my table record without a new search query, it'll be very beneficial. That functionality exists in Oracle, but this feature is not available everywhere in SQL Server. So if SQL Server had the feature, it'd be great because SQL Server is lacking only on this point. For example, one of my clients is a semi-technical person, so I have to train them to file a query in SQL. And they say that Oracle is much better. Say, for example, that I wanted to query a particular employee from a list of all staff. So the query output comes, and they can directly filter out the data by just applying the filter. They don't have to use the drop-down menu and search for all the employees with a given name.
I've been using SQL Server for the last six years. I'm working with SSIS, SSRS, or MDS. These tools are part of SQL Server, and the back-end queries are developed in SQL Server.
SQL Server is stable. SQL Server has crashed only two times in six years, but it wasn't a major system error.
It may be a licensing issue, but sometimes its operating speed becomes slow if we have multiple users. It's lacking some performance, but it's acceptable because we have a heavy load. And I would like to add that we're running SQL Server and SSIS at the same time. So while I've found that SQL Server is quite fast, SSIS is a part of SQL Server. It is just for data testing in India. But if a person knows SSIS, then they usually have very little knowledge about SQL and vice versa.
I know both of them. I found that maybe it's a bad habit, but I'm using SSIS packages. And in the SSIS package, I'm using Toolbox from SQL Server to improve the latency. Implementing both together takes a little time. And one more point is data handling. I am just forwarding the error names, and there are multiple errors in the SQL Server tool, but what if a person comes to work under me and has only one or two years of experience? Sometimes it might be difficult for them to understand what the errors mean. For example, when joining data, it's easy to implement the inner joint. In the inner joint, there are two columns, so when there's an output error, someone who is inexperienced with SQL Server might not understand. Error messages should be a little more precise and defined, so it's easy to understand.
Setting up an individual SQL Server is pretty straightforward, but when you are implementing multiple tools, it's more complicated. In terms of maintenance, for the DBA part, there are two based in my company because I am on a master device, so they don't allow me to maintain the server part. So one person is from South Korea, and the other is from China. They are handling my SQL Server. So maybe there are multiple teams, but I am contacting these two guys, the DBA. And I'm MDS, so I'm a single person. There are two people on my team, and I have one junior staff member. So I have a three-person team, and there are two DBA sites because I'm discussing my master team. I am deployed on the business side, and there are more than 80 people who are end-users of SQL.
If you're using SQL Server along with SSIS and SSRS tools, it works pretty smoothly and all. When working with Oracle SQL, PostgreSQL, MySQL, etc, there are a few problems with the connection.
Overall, SQL Server is good, but sometimes, optimization becomes a little bit tricky when you're using SQL Servers in place of Oracle. For example, while I was implementing two queries one time, the SQL Server gave me the wrong results. This wasn't because of their internal modules. So there may have been some missing data, but SQL Server failed to identify those issues. SQL Server needs to improve there.
For example, say there is a line with a value of 136 or 137. The second value is a space, and the third value is null. And the last one is space. So a space means this is also null. So you are comparing these four values, and if you don't have any idea about data, it's a little problematic. So cases like this, we can deal with such queries using syntax, but if a person has no idea how to deal with this, they'll face an issue.
Here's another example. Say there's a team query that means we are erasing data from the teams, and some people are just analyzing the string. So I see data from it, which means the calling system is there. In the calling system, we receive the data to call anyone, and that type of wire call setup is there. So I am receiving a full-text format from the file I have to upload in the SSIS package. And some cells have a null value. It's a text file, so you can understand there are blanks in some places. I don't know the file type, so I am just trying to dump it into our SQL Server. But when I have time to get to that table, I realize that some values are null, space, and blank. So these four values make problems for me.
I rate SQL Server nine out of 10. I would recommend SQL Server to anyone because you can use cloud-based services, so it's very beneficial. If you install SQL Server on-premise and on the Azure cloud, it is much more advantageous for you.
Currently, I'm doing a lot of source applications with Ruby on Rails, React, and mobile applications. PostgreSQL is my preferred database over MySQL. It's open-source and licenses are free, so it is excellent. The SQL queries are almost the same as MySQL.
Clustering is the number one feature. It is also open-source so it is free. It can also be clustered, to allow fault tolerance. MySQL has to be licensed, but PostgreSQL does all the same things. I have deployed both. You benefit from the way you use it.
It could be improved by using parallelization. We want distributed computing. Some databases handle huge volumes of data better, such as the NoSQL database, MongoDB which can handle 100 000, or a million people using the same data search. PostgreSQL is going to take longer to do this, but it is more structured, and unlike MongoDB data is less likely to be duplicated. Large volumes of data can be handled better in PostgreSQL if the queries are written well.
I have been using PostgreSQL for about 2 years. I used to use version 9, about two years ago but right now I'm using version 10 or 12. I know how to create database functions. I know how to create relationships between data like primary keys and foreign keys etc.
I think PostgreSQL is more stable than MySQL.
As an RDBMS, a relational database management system, it scales well.
I have mainly used the Stack Overflow site for support, which is not technical support in particular. I have never been in a situation whereby I'm stuck and I have to go and ask PostgreSQL support.
The difficulty of the initial setup depends on the application you are deploying the code to. It can be integrated with Docker to enable automation of this process. I put PostgreSQL in a Docker container and then I just collect it. It just works wherever I deploy it. It takes less than three minutes. I use a continuous integration process. The Docker orchestration engine such as Kubernetes or Docker Swarm can be used to integrate with it. I store the code in GitHub or GitLab and your code is always there. Depending on the technology you're using, some things change in your configuration.
I have deployed them to Oracle recently. I've also deployed it in the cloud. There's really nothing special about the cloud, as long as I use the PostgreSQL machine I can deploy it anywhere. I want to deploy it on the Google cloud platform, and Amazon Web Services as these are well known virtual machines.
When it comes to pros, I would put MySQL and PostgreSQL in the same class. let's say I'm trying to write to the database and then the power went off. It will still keep the data integral. I don't have duplicated data, and data integrity is intact. With NoSQL databases I have to duplicate queries in case something like this happens I don't know whether my data is going to be integral in cases like a failure situation. PostgreSQL has the rollback function which remains integral. I cannot build a search engine using PostgreSQL, because that would be a very expensive hit on resources. Alternatively, with the ElasticSearch utility, and the use of load balancing, it is very easy to use. Elasticsearch returns substantial results and works in the background. I cannot do that with MySQL or PostgreSQL databases as that's actually a very expensive use of resources.
My advice would be to use PostgreSQL instead of MySQL because of licensing issues. Another reason is that Oracle may remove MySQL soon or add substantial costs to using it It may even turn into something like MariaDB, and then you would need to know if MariaDB and MySQL work the same? PostgreSQL really works well. There are a lot of other databases around right now, but PostgreSQL is the most popular. It is not like a hammer and a nail situation whereby it is the only thing you have to use. If you need a relational database management system, go for PostgreSQL instead of MariaDB or MySQL, then use it side to side. Can also consider other engines out there, like other NoSQL engines, perhaps.
I would give it an 8 out of 10. PostgreSQL is not suitable for all types of applications, hence why I gave it an 8 instead of a 10.
I use Oracle Database to support the customized Java ERP setup that I currently have.
Oracle Database has improved how we do our administrative backups. The solution has a smaller footprint than 11g, it's more efficient on the resources for the users. It has a smoother user experience with the ERP and fewer field transactions.
Oracle Database is running on the same old hardware that I had the 11g version on and it is operating faster. It seems to be really good. It's fast even when the workload is heavy, easy to do backups and other administrative tasks with the Enterprise Manager.
Oracle Database can automatically assign resources to threads that are heavy. We hardly notice when they are running a heavy query and it is better at managing memory than the older 11g version. When we use the same amount of indexes when migrating to 19c, I didn't have to do any other modification and we have increased usage on the ERP. The Oracle Database is handling everything very well.
Oracle Database could improve by having a better-integrated view of the containerized databases. The Enterprise Manager is great at that, but if there was a centralized view of all the containers it would be a large benefit.
I have been using Oracle Database for approximately one year.
The reliability of the Oracle Database is excellent and the performance is very good. I have used MySQL for large transactions which have given me some problems, but in Oracle Database version 19c I have not had these issues. In the Oracle Database version 11g, sometimes I would have some lagging, but in the newer version, it has been fine.
The scalability of the solution is good.
We have approximately 70 users that are using the solution through the ERP.
The support I have received from Oracle Database has been very great. The response times have been good.
I have previously used MySQL.
The initial setup of Oracle Database is straightforward, it was easy. The migration from an older version was not a problem at all, and it took under one hour.
I did the implementation mostly myself, but because of the ERP setup, I had to have support from the vendor. It was a partnership setup.
I do the maintenance of the solution, we only require one person. I use the solution on a daily basis.
Oracle Database could make the documentation better around licensing. The way you have to access software from Oracle is difficult. You have to go through the licensing lawyer to understand what your reach is when you subscribe to one unit. I wish the documents were easier to understand for everyone. This is a problem I have always grappled with and it's not changed. Having clarity is even more important now that I'm thinking of having a hybrid setup for the database in the cloud for high availability.
The cost of the solution is reasonable. It costs approximately $4,000 with some extra features we have.
I would recommend this solution to others. However, it does depend on different organizations and their needs. If the resources are a little heavy, which makes for disaster recovery planning, a little bit tricky.
I would advise people to explore how their workloads would be and if they can be containerized in the cloud. That would make it way easier for them to manage them. The scalability of Oracle Database is very easy to grow or shrink as the need.
I rate Oracle Database a nine out of ten.
Our software development team uses MariaDB and other databases as the storage facility for some of our applications.
Initially, we liked this solution because it is a drop-in replacement for MySQL.
The most valuable feature is that it uses multiple cores, which is better than some of the other databases. When we have eight or sixteen cores, the utilization ratio is a bit higher than previous versions of MySQL. I think perhaps the enterprise version of MySQL may have better support, but the free version does not work as well as MariaDB. This is with the factory default settings.
Scalability is an area that needs to be improved.
When we have had issues with accidental computer shutdown or a power outage, our MariaDB database was corrupted. This did not happen with our Oracle or Microsoft SQL Server, so I think that there might be some differences in the database engine that better deals with these kinds of accidents.
We have been working with MariaDB for seven years, since 2013.
We have not experienced much in terms of instability. We have been running our instance since 2013 and it needs almost no maintenance. You just install it and forget it. It's that easy.
MariaDB works with just a little configuration for a small dataset, but it does not scale as well as Oracle of Microsoft SQL Server in our applications. For example, additional manual configuration or tweaks are needed so that a query will return in a reasonable time when there is a high volume of records.
Our client has between 10 and 30 concurrent users.
Getting proper support is sometimes difficult because when you have a technical issue and use Google to try and find a solution, there will be millions of results. You have to tackle it by yourself but even if there is the same error message, you can try every posted solution and it still might not work. There is not a single source of truth that you can rely on.
The initial setup is straightforward and I think that the installation can be completed in a couple of minutes.
We have our own team for deployment and maintenance.
I think that for a small team of fewer than ten people, such as a couple of developers, MariaDB is a very easy start. When the team size grows or when the complexity of the application grows, you might need to try other options such as Ingres or MySQL. In our case, at the very beginning, MariaDB covered almost every technical requirement for releasing version one of our application.
It is definitely a good start. Once the product has grown to a point where the developers know in which aspect MariaDB does not fulfill the requirements, then it's time to find a better match.
At this point, I cannot think of any additional features that I would like to see because most of what I want is already on the roadmap. I think that they plan to implement them one by one.
I would rate this solution an eight out of ten.
Oracle Java DB is one of the databases we use, and we use quite a few databases. It's either Oracle or Microsoft SQL Database or MySQL. We've been doing it for many years, but all our clients work on different databases. They use non-transactional and non-relational databases. One of our clients also uses MongoDB.
Oracle Java DB isn't used much as many of our clients use Microsoft SQL Server Database. We have a client in the healthcare space that is using it, and we use this for storing all the information of this space.
It's very clever. Oracle Java is one of the first object-oriented languages that we've had. A lot of the data and the languages are in Python. I think the concept is the same. But Oracle Java is very object-oriented. I think Java was one of the first to come out with object-orientation. I used Java to develop the APIs, and it's recommended, and we use it.
It'll be better if Oracle Java supports open source technologies, like Node.js. Many APIs can be developed in applications like Node.js, and it's a lot easier to use a programming language like Node.js because it's totally open-source and available. It also has a lot of APIs that I can download and access from anywhere.
You can, of course, use microservices, but I think the marketing around microservices products isn't working, and a lot of folks seem to be using Node.js and Angular as their programming languages for API development.
Oracle Java also supports a lot of the microservices concepts, and a lot of the work can be done within that. Java needs to come out with a lot more and let us do more with the UI. This will benefit the future of Java.
We have been using Oracle Java DB for many years.
Oracle Java DB is very stable.
It's scalable, but it depends on how you deploy it. As long as you're not using monolithic applications, it's scalable.
Technical support has been very clear and convenient, and we can always reach out to them.
The initial setup is easy, and the deployment time is really nothing.
Quite a few clients would look at Python or Node.js. If you take Python as an example, it also supports machine learning.
This is a fairly stable language, and it's been in the market for several years. In fact, it's been around since about 1995, when the concept of object orientation started. People should use it because it's clever.
On a scale from one to ten, I would give Oracle Java DB a nine.
