I am doing an ODBC based SQL client and I need to store a boolean value - what is the most portable SQL data type to use for the corresponding column? I already saw the related questions What is the best data type to store boolean values in a database? and Are there reasons for not storing boolean values in SQL as bit data types?, but they do not cover portability per dbms. I assume TINYINT is the way to go since it seems that at least MySQL and MSSQL support it, but maybe someone can give a more precise answer from experience?
Related
which data type is best suited to store boolean value in postgresql 9.2 in compare of memory. please i am confusing that should i use bit or TINYINT or boolean to store boolean values. And which one is supported by ms sql server,oracle and postgresql databases. Please suggest me. Thanks
Postgresql supports the boolean type: http://www.postgresql.org/docs/current/static/datatype-boolean.html
In MS SQL Server bit type uses for storing boolean: http://msdn.microsoft.com/en-us/library/ms177603.aspx
Oracle doesn't support boolean type, but it possible to store boolean values in CHAR(1) as Y/N or in NUMBER(1) as 0/1: Is there a boolean type in oracle databases?
I am loading data from a sqlite database into a ms SQL database.
The field type in the Sqlite is Numeric.
What is the best field type to use so that I don't loose any detail?
What is the underlying data representing? Numeric in SQLite is a technically a column affinity and not a storage type. Other databases do not have the concept of "column affinity", which is explained here. In SQL Server, the types describe how the data is being stored.
The intention of a numeric column affinity is probably a fixed point numeric value. In that case, decimal/numeric would be the right type in SQL Server.
Note that numeric can also apply to dates, datetime, and boolean values. You would want to store these with the corresponding data types in SQL Server (probably date, datetime, or bit).
My understanding of SQLite is limited, but from what I'm reading here: Datatypes in SQLite, the numeric affinity does not seem to actually tell you much about the data contained therein.
If that's the case, the best thing to do is to query the values to see what you're dealing with, then decide. Odds are it will be a FLOAT or DECIMAL.
The best type to convert a NUMERIC column from SQLite to SQL Server is DECIMAL.
http://msdn.microsoft.com/en-us/library/ms187746.aspx
I am designing a table that will store login information, which includes a persons name.
There will be lots of inserts and deletes to this table, but no updates.
I am wondering what is the best datatype to use? varchar(50)? nchar(50)?
Optimise for speed, need names in various languages.
The safest way is to use nvarchar. That way you can accept names in multiple languages.
http://weblogs.asp.net/guys/archive/2005/01/15/353550.aspx
The safest is doubtless nvarchar as stated by #Kevin in his answer.
For speed, however, varchar is half the size of an nvarchar, making it more compact for storage, and faster for access
Have a look at the following aticle:
http://msdn.microsoft.com/en-us/library/aa196741(SQL.80).aspx
I'm not sure how to explain this probably, so I'll use an example.
I have to store (etc.) some users ID in a single value/column in my SQL Server table, so one value could look like this "4231 3271 3722 7432 4831 3192 ". of course this can be stored as a text, char, nchar, nvarchar and som on. But which is the best? if I have to only store integers(and something to separate them)?
So what is the best way to store multiple integer values inside a single SQL Server cell?
And you don't have to post me any alternative ways to do this, as this is just an example, and it is the only right way to do this, even if I have to use varchar :)
I know you asked us NOT to provide alternate ways of doing this, but here goes:
Normalize!!!
Basically, you create another table with a minimum of 2 columns (UserId and the primary key of the table you described above). This way, you can have any number of User IDs for a single record in this table. You also have the value of placing only ONE User ID in a single column.
Now... If you want to do it the way you described anyway, here is what you can do:
You cannot put multiple integers in a single column and still use the datatype int. You will have to use a text type of some kind (varchar, nvarchar, etc). You should have a common, easy to read delimiter (if they are all integers, then a space or comma will work just fine).
Doing this will cause you problems down the road, and I really encourage you to do it with normalization.
what is the best way to store multiple integer values inside a single SQL Server cell?
Simple - you don't.
CHAR and VARCHAR have a maximum of 8,000 characters. The spaces in your example impact that as well - in your example, the integers with a length of 4 plus the 1 character for the space means you could have a maximum of 1,600 distinct values. Even if you stored the values in XML, which SQL Server supports up to a max of 2 GB, you'll have to use XPATH/XQUERY to get the values out of the XML markup.
There's reliable way to keep the data consistent (spacing, characters) when using this approach, making getting the data out a problem waiting to happen.
The Best approach is to normalize the data:
There's no limitation to the number of associations
Reliable data enforcement - an INT column won't allow alphabet characters
Data manipulation performance is far better, because there's no conversion
I agree with the others: Normalize. But I'll add an actual solution as well, which is to use a CLR type. hierarchyid is technically a sequence of integers, but it's difficult to get at the actual "numbers" stored inside. You can write your own CLR data type to store a nested set and generally get better type safety and efficiency than storing it as a varchar or something similar.
Please note, I am not actually recommending this for typical databases. Nested sets do have their uses, but those uses are fairly rare. You should always use 3NF for an OLTP database unless it's a performance issue.
I'm working on an application developed by another mob and am confounded by the use of a char field instead of bit for all the boolean columns in the database. It uses "Y" for true and "N" for false (these have to be uppercase). The type name itself is then aliased with some obscure name like ybln.
This is very annoying to work with for a lot of reasons, not the least of which is that it just looks downright aesthetically unpleasing.
But maybe its me that's stupid - why would anyone do this? Is it a database compatibility issue or some design pattern that I am not aware of?
Can anyone enlighten me?
I've seen this practice in older database schemas quite often. One advantage I've seen is that using CHAR(1) fields provides support for more than Y/N options, like "Yes", "No", "Maybe".
Other posters have mentioned that Oracle might have been used. The schema I referred to was in-fact deployed on Oracle and SQL Server. It limited the usage of data types to a common subset available on both platforms.
They did diverge in a few places between Oracle and SQL Server but for the most part they used a common schema between the databases to minimize the development work needed to support both DBs.
Welcome to brownfield. You've inherited an app designed by old-schoolers. It's not a design pattern (at least not a design pattern with something good going for it), it's a vestige of coders who cut their teeth on databases with limited data types. Short of refactoring the DB and lots of code, grit your teeth and gut your way through it (and watch your case)!
Other platforms (e.g. Oracle) do not have a bit SQL type. In which case, it's a choice between NUMBER(1) and a single character field. Maybe they started on a different platform or wanted cross platform compatibility.
I don't like the Y/N char(1) field as a replacement to a bit column too, but there is one major down-side to a bit field in a table: You can't create an index for a bit column or include it in a compound index (at least not in SQL Server 2000).
Sure, you could discuss if you'll ever need such an index. See this request on a SQL Server forum.
They may have started development back with Microsoft SQl 6.5
Back then, adding a bit field to an existing table with data in place was a royal pain in the rear. Bit fields couldn't be null, so the only way to add one to an existing table was to create a temp table with all the existing fields of the target table plus the bit field, and then copy the data over, populating the bit field with a default value. Then you had to delete the original table and rename the temp table to the original name. Throw in some foriegn key relationships and you've got a long script to write.
Having said that, there were always 3rd party tools to help with the process. If the previous developer chose to use char fields in lieu of bit fields, the reason, in a nutshell, was probably laziness.
The reasons are as follows (btw, they are not good reasons):
1) Y/N can quickly become "X" (for unknown), "L" (for likely), etc. - What I mean by this is that I have personally worked with programmers who were so used to not collecting requirements correctly that they just started with Y/N as sort of 'flags' with the superstition that it might need to expand (to which they should use an int as a status ID).
2) "Performance" - but as was mentioned above, SQL indexes are ruled out if they are not 'selective' enough... a field that only has 2 possible values will never use that index.
3) Lazyness. - Sometimes developers want to output directly to some visual display with the letter "Y" or "N" for human readableness, and they don't want to convert it themselves :)
There are all 3 bad reasons that I've heard/seen before.
I can't imagine any disadvantage in not being able to index a "BIT" column, as it would be unlikely to have enough different values to help the execution of a query at all.
I also imagine that in most cases the storage difference between BIT and CHAR(1) is negligible (is that CHAR a NCHAR? does it store a 16bit, 24bit or 32bit unicode char? Do we really care?)
This is terribly common in mainframe files, COBOL, etc.
If you only have one such column in a table, it's not that terrible in practice (no real bit-wasting); after all SQL Server will not let you say the natural WHERE BooleanColumn, you have to say WHERE BitColumn = 1 and IF #BitFlag = 1 instead of the far more natural IF #BooleanFlag. When you have multiple bit columns, SQL Server will pack them. The case of the Y/N should only be an issue if case-sensitive collation is used, and to stop invalid data, there is always the option of a constraint.
Having said all that, my personal preference is for bits and only allowing NULLs after careful consideration.
Apparently, bit columns aren't a good idea in MySQL.
They probably were used to using Oracle and didn't properly read up on the available datatypes for SQL Server. I'm in exactly that situation myself (and the Y/N field is driving me nuts).
I've seen worse ...
One O/R mapper I had occasion to work with used 'true' and 'false' as they could be cleanly cast into Java booleans.
Also, On a reporting database such as a data warehouse, the DB is the user interface (metadata based reporting tools notwithstanding). You might want to do this sort of thing as an aid to people developing reports. Also, an index with two values will still get used by index intersection operations on a star schema.
Sometimes such quirks are more associated with the application than the database. For example, handling booleans between PHP and MySQL is a bit hit-and-miss and makes for non-intuitive code. Using CHAR(1) fields and 'Y' and 'N' makes for much more maintainable code.
I don't have any strong feelings either way. I can't see any great benefit to doing it one way over another. I know philosophically the bit fields are better for storage. My reality is that I have very few databases that contain a lot of logical fields in a single record. If I had a lot then I would definitely want bit fields. If you only have a few I don't think it matters. I currently work with Oracle and SQL server DB's and I started with Cullinet's IDMS database (1980) where we packed all kinds of data into records and worried about bits and bytes. While I do still worry about the size of data, I long ago stopped worrying about a few bits.