Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
We all have our favourite database. If you look objectively at your chosen database, what drawbacks does it have and what could be improved?
The rules:
One reply per drawback with;
a short description of the limitation, followed by;
a more detailed description, an explanation of how it could be done better or an example of another technology that does not have the same limitation.
Do not diss any database that you haven't used extensively. It is easy to take potshots at other technologies but we want to learn form your experience, not your prejudice.
Oracle databases are quite expensive
Oracle does what it does well but the licensing costs are horrendous. That has been improved by the release of Oracle XE but the limitations of that mean that it is a growth constraint on you solution.
Database Microsoft SQL Server 2005
Defect Lack of "INSERT OR UPDATE"
Description
Often you need to either insert or update a record in a table, depending on whether the record is present or not. Not having an atomic operation to do so leads to unnecessary transactions.
This does not happen with MySQL or SQLServer 2008.
Database PostgreSQL
Defect No SQL Profiler
We asked the developers about this at a recent conference and I understand it's now something they're looking to implement.
I love the flexibility of sequences in Oracle as compared with other databases autoincrements, but the inability to set seq.nextval as a default for a pk column is somewhat annoying, and must be trivial to fix.
Database Microsoft SQL Server
Defect Huge licensing cost
Description
SQL Server has great features and it integrates very well with .NET development. The issue is that when you have to scale up from a shared database to a dedicated database, licensing costs are really high. This, in effect, leads to databases which should really run on a dedicated server, being hosted on shared servers with performance and security issues.
This does not happen with MySQL or PostgreSQL.
Database Microsoft SQL Server 2005
Defect Badly implemented UI
Description
SQL Server management studio does not offer a great user experience:
Tabbing behaviour is weird: you are always looking for the right tab
Keeps on crashing on 64-bit versions
Missing some features of preceding version, like overview of grants of stored procedures
This does not happen with version 2000.
Database MySQL
Defect Server will start up with damaged tables
Description
If MySQL has a damaged table - from either being killed during a write or some other failure - it will quite happily start up and allow the user to carry on as if the problem does not exist. Granted it will produce some error messages in the log, but from my experience this doesn't help when you're trying to figure out why an application is behaving oddly.
Most other databases will detect and repair the error on startup or simply refuse to start with any sort of corruption.
Database MySQL 5.0.x and above
Defect Ring replication errors lead to inconsistent data on different nodes
Description
The most serious problem in production we face at the moment is that in a MySQL ring the ring itself produces an error and stops replicating.
Building a ring (or Master-Master-replication) is possible since 5.x.x: You chain the databases in a "ring" so that the replicate data to each other. Every database-node gets all the changes from all other nodes.
We assume that the error lies behind autoincrement- failures. This is known from normal replication, too, but in the new version there are no sufficinet error messages in the error log. I highly recommend not to use this feature in MySQL as long as the problems here are not fixed.
Database Oracle
Defect Did not handle long datatype well for too long
Description
Oracle only had the long datatype until 9i (I believe) at which point it was deprecated in favor of the LOBs. There is a ton of code out there, however, which still has longs and all of the related restrictions. The biggest of which was that each table could only have one long column and it had to be at the end of the columns. See here for a more exhaustive list of restricitons on the long.
Database Oracle
Problem Temp table definitions are not private
Description Many databases (eg Postgres and Sybase) allow you to create temp tables on the fly, insert into them, add indexes if you want, then query from them. Oracle has temp tables, but the temp table definitions exist in a global name space. Therefore the temp table has to be created by a DBA, you need to synchronize between the table definition they used and your code, and if two pieces of code want similar (but not identical) table definitions, they need to use different names. These differences make temp tables far less convenient for developers.
Yes, I understand the benefits for the query optimizer of having global definitions. However for me the lack of convenience makes Oracle's temp tables virtually useless for me, while I use them very intensively in Postgres.
Database: Oracle
Problem: The names of tables, procedures, columns, etc cannot exceed 30 characters. This is infuriating.
Problem: It's slapdash JDBC compliance. For example, stored procedures do not return results sets in a JDBC-compliant way, but instead of a proprietary OUT parameter type. This means you can't use higher-level JDBC abstractions.
Database MySQL
Defect Foreign Keys supported only on some table types
Description
Enough said. It has obvious maintenance implications.
From the MySQL manual
Foreign keys definitions are subject to the following conditions:
Both tables must be InnoDB tables and they must not be TEMPORARY tables.
And here:
For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY syntax in CREATE TABLE statements, but does not use or store it.
This does not happen with any other major DB.
PostgreSQL doesn't have a good failover solution, but I understand they're working on it.
Database : Sql Compact Edition
Drawback : Stored procedures are not supported.
Regardless of this limitation, this DB has its' uses especially as a client cache for application that can be smart client or distributed to mobile platforms.
Database Oracle
Defect Granularity of grants on packages
Description
You can only grant permissions on packages and not on stored procedures inside packages. Or alternatively, you can grant permissions on single stored procedures but then you put them outside of packages. This requires you to know up front who will use which stored procedure and it is really hard to refactor.
This does not happen with SQL Server.
Database Microsoft SQL Server 2005
Defect Lack of array type parameters
Description
Useful in searches, a lot of times you need to pass a series of values to be matched against. In SQL 2005 you can do a workaround by using CLR inside SQLServer. Given the usefulness it would make more sense to have this feature out of the box.
This does not happen with SQL Server 2008 or Oracle.
Database Postgres
Defect No analytic queries
Description
Analytic queries, introduced by Oracle, are part of the SQL 2003 standard. Unfortunately Postgres hasn't implemented them yet.
Database : PostgreSQL
**Problem : ** is that connector for C# for example are not really up-to-date and crash with advanced feature.
Database: All
Drawback - Poor design by people who didn't think it was important to know what you were doing when you designed a datbase. Far more problmes caused in all databases by bad design than from any missing feature. So I suppose they are all missing the "read my mind and figure out the best solution without me having to think" feature.
Any SQL DBMS
Defect: Duplicate rows
One of the virtues of the relational model is that it represents everything without duplicate tuples, i.e. using relations, which have keys and no duplicates. Unfortunately SQL isn't built that way. This makes the database developer's life needlessly difficult. SQL developers have to deal with tables without keys and debug queries that return duplicate rows.
Related
I want to know how can I know the relationship in the database which is not determined by the primary key in the design
For example I have three tables in the database following like this :
Table 1 : fields
Table 2 : area
Table 3 : location
and all of the tables have data but who created database did not explain the primary keys and the foreign keys in it, so how can i know the relationship between this tables?
Note : I am using SQL Server 2008
If there's no documentation at all and no defined foreign keys, your options are:
Look at the application source code to see what it's doing. This may or may not be available to you. If it isn't, you're in a fair bit of trouble.
Contact whomever wrote the application originally and ask them for help or documentation. This may or may not be possible.
Guess. I'm certain you'll have to do a lot of this no matter what.
Run the application while SQL Profiler is Trace Capturing the SQL queries sent to the DB, or using Extended Events in SSMS. I don't recommend running Profiler on a production DB due to the performance impact. I've never used Extended Events, but I know that they're replacing Profiler's capture abilities in forthcoming editions of SQL Server. Neither of these tools is particularly simple (Profiler isn't; Extended Events don't look any better from the doc). You're going to need to read a fair bit of documentation.
I have a big SQL Server 2012 database.
I want to split it into preferences and data.
However I find that SQL Server does not seem to support the idea of dividing your data up into object oriented databases. It seems to rely on everything being in the same database.
For example foreign keys are not supported in database. Also cross database joins are a real pain to do.
How would someone typically go about doing this? Is it just a limitation of SQL Server that I should use the same DB for everything?
SQl Server provides partitioning feature. As per wikipedia
A partition is a division of a logical database or its constituting elements into distinct independent parts. Database partitioning is normally done for manageability, performance or availability reasons
1.Horizontal partitioning
2.Vertical partitioning
Each has it is own file group.it can be configured
Visit this links that should help
MSDN
SQLAuthority
I am sure there are plenty of tutorials out there.
SQL Server is a relational database, so there really shouldn't be an expectation that it would support a fundamentally different architecture implied by an object or object-oriented database.
I don't understand your comment that "foreign keys are not supported in database." Foreign keys are all part of the integrity constraints in SQL Server, and a detail description of how to create them is available here
I think you might want to be more specific about the type of data you're trying to split up, and why you want to put them in physically separate databases. A refinement of your problem might help us provide better answers.
I am developing a data driven website and quite a lot of programming logic resides in database stored procedures and database functions. I found myself changing the stored proc/functions quite a lot in order to fix bugs or add new functionality. The data (tables) have remained mostly untouched.
The issue I am having is keeping track of versions of stored proc/functions. Currently I am incrementing version of whole database when I do a set of changes. As data is huge (10 Gb) I get issues having to run development version and release versions of databases in parallel.
I wish to put all the stored procs and functions in one database and keep data in one database, so that I can better manage the changes.
I am sure others would have encountered similar suggest and request suggestions on how to best handle this situation.
I would also recommend using source control keyword expansion in your stored procedures ($Version:$)
That way you can eyeball, grep, search syscomments, etc to see what version you have on your deployed database.
You can version just the schema dumps. In combination with source control keword expansion (as suggested by Rawheiser), you just take a look at what version you have in the database, generate a diff and apply it.
Also, there are several excellent tools to compare databases and their schemas, generate DDL scripts etc.: SQL Workbench, Power Architect, DDLUtils and Redgate SQL Compare, to name a few. SQL Compare is likely to work best with SQL Server, although all the others are FOSS and provide a higher ROI (in terms of time spent learning and what you can do with them) as they are platoform and RDBMS independent.
Finally, I have to say...I understand that the immediate results you get with logic in the DB are tempting, but if you've gone beyond more than a couple of procedures in the database, you're setting your self up for quite a lot of pain, sifting through what easily turns into spaghetti code and locking your application to a single database vendor. You might have your reasons, but I've been there and didn't like it very much. Logic can live very nicely in a different layer.
For source control you have several options:
Use a Visual Studio Database project.
Use SQL Server 2005's built-in support for source control
Use a third part tool such as SQL Compare
IMO Option 1. is preferable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Has anyone used all three of these databases? What are your experiences with them? PostgreSQL looks pretty tempting for a project but I'm curious to learn more about it (We're a .NET Shop). I've also heard of quite a lot of people being satisfied with DB2.
I work in a very large organization that uses DB2 primarily on Linux (Red Hat). We have a number of large databases and have investigated moving to other RDBMS solutions, such as Oracle and SQL Server. I did a lot of work on the SQL server end of that.
We found that SQL server performs much better and requires less tuning than DB2, especially when tables frow larger than 1M records. HADR is also difficult and bulky, to say the least.
We found many differences between DB2 and SQL Server, and too many to list here. I was responsible for doing a lot of the engineering behind code conversion from one platform to another, and can't say I found anything in DB2 to be superior to SQL server, but did find many things I liked better about SQL server. Here are some off the top of my head:
Better selection data types in SQL Server, such as MONEY and SMALL MONEY.
Mixed character encoding in SQL Server. Some columns can be ANSI and others UNICODE (char and nchar, respectively). Setting this up in DB2 is neither straightforward nor easy.
Better tools in SQL server, mainly SSIS for ETL (As opposed to the insanely priced IBM Data Stage).
SQL server has more forgiving syntax. For example, you don't need semi-colons everywhere. Maybe just a personal preference but I found it much easier to code in T-SQL.
Many advanced features seem to work better in SQL server. For example, SQL server lets you do page-level compression, where DB2 is limited to row-level compression.
It was easier to tune SQL Server queries with the SQL Server IDE
There are more, but honestly I suggest that anyone who is considering one over the other should set both up and spend some time working with both systems. Right now it seems like SQL server is a better overall solution, but DB2 may one day take the crown.
Lastly, when dealing with data warehousing, SQL, SSIS, and SSAS made a much better solution than InfoSphere, DataStage, and DB2. I could write a whitepaper on it, but my suggestion here is to set it up on your own and spend a week or to playing with each solution. Microsoft's solution here was faster and cheaper than IBM's. I don't know of any other basis upon which to make a decision.
Platform shouldn't be an issue since databases generally run on their own machines, but there are always those "no microsoft!" and "no linux!" shops around. It's a shame, really. I'd recommend SQL server.
As a DB2 person, I can offer a few details about what you could expect from running DB2 for Windows and developing .NET applications for it. The following details were current as of version 9.7, which was released in June 2009.
Drivers and API support for just about any Windows programming language and IDE, including .NET and Visual Studio extensions
A no-cost, production-ready database engine (Express-C) that has no database size limit and is the least restricted when compared to Oracle Express and SQL Server Express
A self-tuning database engine for Windows that automatically handles the sizing of several memory buffers that are critical to good performance
Rock-solid support for XML as a native datatype, handled by its own dedicated query engine that is optimized for XML's hierarchical nature. Queries can access any combination of XML and tabular data with any combination of SQL and XQuery expressions
Avoid microsoft like the plague. Always push to use PostgreSql even on windows, way better support for developing applications for e.g. Java/Python and still has good support in .NET. Also of course is completely free which given the current license fees for SQL Server is nothing to be sniffed at even if you're a multi-million dollar company.
For the cost of 1 SQL Server license you are going to save £30,000 (say $40,000) or more - buy better hardware to run Postgres on and still have a net benefit.
As far as performance, really if this is such a massive issue we should not be using either DB2, SQL Server or Postgres anyway. The difference between the three is negligible for their design purposes.
Edit: On the .NET integration, actually this is really poor in SQL Server anyway, it does have more features than Postgres/DB2 admittedly but it's not really hugely advantageous over SSIS or stored procedures. I could see the main use case in my work as accessing classes and functions from a CLR .dll but then you're implementing logic in the database which may or may not be a good idea for you.
If you're a .NET shop, and are either using a small database (i.e. Sql Server Express), or have the money for the full SQL Server, use it. SQL Server will perform better than PostgreSQL for most actions, and about the same as DB2.
PostgreSQL is fantastic if you need multi-platform support, are Linux-based, or need a free product that's not Microsoft.
I haven't used DB2 in over 10 years, other than running an in-house performance test vs. other databases (where it was about the same for a transactional database as Oracle/SQL Server, where were better than MySQL, PostgreSQL, etc).
If you are a .net shop stay with SQL Server.
Using any other database platform would require non-Windows to get the best out of it. On Windows, SQL Server is king simply because MS own both OS and SQL Server (Like Oracle/Red Hat).
The application I want to build using MS Visual C# Express (I'm willing to upgrade to Standard if that becomes required) that needs a database.
I was all psyched about the SQL Server Compact - because I don't want the folks who would be installing my application on their computers to have to install the whole of SQL Server or something like that. I want this to be as easy as possible for the end user to install.
So I was all psyched until it seems that there are limitations to what I can do with the columns in my tables. I created a new database, created a table and when I went to create columns it seems that there isn't a "text" datatype - just something called "ntext" that seems to be limited to 255 characters. "int" seems to be limited to 4 (I wanted 11). And there doesn't seem to be an "auto_increment" feature.
Are these the real limitations I would have to live with? (Or is it because I'm using "Express" and not "Standard"). If these are the real limitations, what are my other database options that meet my requirements? (easy installation for user being the biggie - I'm assuming that my end user is just an average user of computers and if it's complicated would get frustrated with my application)
-Adeena
PS: I also want my database data to be encrypted to the end user. I don't want them to be able to access the database tables directly.
PPS. I did read: http://www.microsoft.com/Sqlserver/2005/en/us/compact.aspx and didn't see a discussion on these particular limitations
I'm not sure about encryption, but you'll probably find this link helpful:
http://msdn.microsoft.com/en-us/library/ms171955.aspx
As for the rest of it:
"Text" and "auto_increment" remind me of Access. SQL Server Compact is supposed to be upgrade compatible to the server editions of SQL Server, in that queries and tables used in your compact database should transfer to a full database without modification. With that in mind, you should first look at the SQL Server types and names rather than Access names: in this case namely varchar(max), bigint, and identity columns.
Unfortunately, you'll notice this fails with respect to varchar(max), because Compact Edition doesn't yet have the varchar(max) type. Hopefully they'll fix that soon. However, the ntext type you were looking at supports many more than 255 bytes: 230 in fact, which amounts to more than 500 million characters.
Finally, bigint uses 8 bytes for storage. You asked for 11. However, I think you may be confused here that the storage size indicates the number of decimal digits available. This is definitely NOT the case. 8 bytes of storage allows for values up to 264, which will accomodate many more than 11 digits. If you have that many items you probably want a server-class database anyway. If you really want to think in terms of digits, there is a numeric type provided as well.
A few, hopefully helpful comments:
1st - do not use SQLite unless you like having to have the entire database locked during writes (http://www.sqlite.org/faq.html#q6) and perhaps more importantly in a .Net application it is NOT thread safe or more to the point it must be recompiled to support threads (http://www.sqlite.org/faq.html#q6)
As an alternate for my current project I looked at Scimore DB (they have an embedded version with ADO.Net provider: http://www.scimore.com/products/embedded.aspx) but I needed to use LINQ To SQL as an O/RM so I had to use Sql Server CE.
The auto increment (if you are referring to automatic key incrementing) is what it always has been - example table:
-- Table Users
CREATE TABLE Tests (
Id **int IDENTITY(1,1) PRIMARY KEY NOT NULL,**
TestName nvarchar(100) NOT NULL,
TimeStamp datetime NOT NULL
)
GO
As far as the text size I think that was answered.
Here is a link to information on encryption from microsoft technet: (http://technet.microsoft.com/en-us/library/ms171955.aspx)
Hope this helps a bit....
Had to chime in on two factors:
I use Sql Compact a lot and its great for what it works for -- a single user, embedded, database, with a single file data store. It has all the SQL goodness and transactions. It hadles parallellism well enough for me. Notice that few of the naysayers on this page use the product regularly. Don't use it on a server, that's not what its for. Many of my customers don't even know the file is a "database", that is just an implementation issue.
You want to encrypt the data from your users -- presumably so they can only view it from your program. This simply isn't going to happen. If your program can decrypt the data, then you have to store the key somewhere, and a sufficently dedicated attacker will find it, period.
You may be able to hide the key well enough that the effort to recover it isn't worth the value of the information. Windows has some neat machine and user local encryption routines to help. But if your design has a strong requirement that a user never find data you have hidden on their computer (but your program will) you need to redesign -- that guarentee simply cannot be accomplished.
SQL CE is a puzzle to me. Did we really need yet another different SQL database platform? And it's the third in the last several years targeted at mobile platforms from MS ... I wouldn't have a lot of confidence that it will be the final one. It doesn't share much if any technology with SQL Server - it's a new one from scratch as far as I can tell.
I've tried it, and then been more successful with both SQLite and Codebase.
EDIT: Here is a list of the (many) differences.
ntext supports very large text data (see MSDN - this is for Compact 4.0, but the same applies to 3.5 for the data types you are mentioning).
int is a numeric data type, so the size of 4 means 4 bytes/32 bits of storage (–2,147,483,648 to 2,147,483,647). If you intend to store 11 bytes of data in a single column, use the varbinary type with a size of 11.
Automatically incrementing columns in the SQL Server world are done using the IDENTITY keyword. This causes the value of the column to be automatically determined by SQL Server when inserting data into a row, preventing collisions with any other rows.
You can also set a password or encrypt the database when creating it in SQL Compact to prevent users from directly accessing your application. See Securing Databases on MSDN.
All of the items you mention above are not really limitations, so much as they are understanding how to use SQL Server.
Having said that, there are some limitations to SQL Compact.
No support for NVARCHAR(MAX)
NTEXT works just fine for this
No support for VIEWs or PROCEDUREs
This is what I see as the primary limitation
I've used the various SQL Server Compact editions on a few occasions, but only ever as data capture repositories on mobile platforms - where it works well for syncing with a server database, and with that sort of scenario is undoubtedly the optional choice.
However if you need something to do more than that and act as a primary database to your application then I'd suggest SQLLite is probably the better option, it's completely solid, widely supported and found in all sorts of places (used on the iPhone for example) but is surprisingly capable (The Virtual Reality simulator OpenSim uses it as it's default database) and there are lots of others (including Microsoft).
I must also chime in here with VistaDB as an alternative to SQL CE.
VistaDB does support encryption (Blowfish), it also supports TEXT as well as NTEXT (including FTS indexes on them).
And yes the post above is correct in that you have to look at the SQL Server types to really match them up, VistaDB also uses the SQL Server types (we actually support more than SQL CE does; only missing XML).
To see other comparisons between VistaDB and SQL CE visit the comparison page. Also see the SO thread on Advantages of VistaDB for more information.
(Full disclosure - I am the owner of VistaDB so I may be biased)
According to this post (http://www.nelsonpires.com/web-development/microsoft-webmatrix-the-dawn-of-a-new-era/) it says that because it uses a database file, only one process can access it for every read/write and as a result it needs exclusive access to the file, also it is limited to 256 connections and the whole file will most likely have to be loaded in memory. So SQL server compact might not be good for your site when it grows.
There are constraints... Joel seems to have addressed the details. SQL CE is really geared for mobile development. Most of the "embedded" database solutions have similar constraints. Check out
SQLite
No TEXT field character limit
Auto increment only on INTEGER PRIMARY KEY column
Some third party encryption support
Esent
(unmanaged code isn't my forte, and I can't decipher the unmanaged docs)