I have a situation which I can resolve by adding a column which would be a datetime or a ntext type.
In terms of performace, which of these would be better to use. The number of records are more than 60000. I was thinking datetime since I could index on it, but not sure if ntext can be...any suggestion or discussion on which would handle memory,speed better...or any other performance issues?
Update: the column i will add are independent- one is date time and other is text, i can resolve the issue by having anyone, NOTE: I am not trying to store datetime as ntext here.
60000 records is nothing for SQL Server.
So there shouldn't be any noticeable difference. Maybe there would be a difference if it was a REALLY big table (hundreds of millions of records, and above...), but not with your amount of data.
However, as the others already said: your statement that you can either use datetime or ntext sounds very strange to me. If it's really date and/or time values, use datetime and not ntext!!!
EDIT:
Now that you clarified that you don't want to store date values in a text column:
I would suggest that you use the datetime column. It's better than ntext performance wise.
As a side note: if you prefer to use the text column, you should use nvarchar(max) instead of ntext. ntext is slower and deprecated.
If the data is a DATETIME, use a DATETIME.
You will have problems querying a text field when you need to do date and time operations.
Performance wise - DATETIME is 8 bytes and NVARCHAR for storing a date will be longer. Operations that require date/time work will require conversions with an NVARCHAR field, which will be more expensive than simply using a DATETIME column.
These are two completely different fields. If you need to store dates use datetime, if you need to store text use varchar or long text. Do not store dates as text!
Related
As the title says, when creating a table with a column of time type, the column defaults to datetime type. Is this normal or a bug? Here's the relevant line when creating the table:
Create Table dbo.time(
ColumnOfTime time)
And here's what's created:
ColumnOfTime [DATETIME Nullable]
Again, is this normal or have i done something wrong? Not much of a SQL person and the tinternet doesn't seem to offer much advice. Thanks
If you have SQL Server 2000, you can either use the datetime datatype, and just ignore the date portion when you work with it, or you can store time as a varchar or integer (maybe seconds after midnight) and do the necessary casting and/or calculations when you work with it.
My question is similar to some other questions here in Stackoverflow, but none of them worked for me. I have date and time column in the format 1991-04-01 00:00:00.000, and I want to convert it to this format: 19910401
I have tried this code below:
Update [TestFamily].dbo.List
set dbo.List.DtBirth = convert(
varchar(10), cast(dbo.List.DtBirth as
datetime ),112)
after executing it says 320104 rows affected , but actually nothing has changed , the date format remains the same.
Every suggestion will be appreciated.
DateTime data in SQL Server doesn't have a format. They are just values that are only changed to a certain format when you display them. So it is taken into account when you view the results of a query in SSMS, show them in an app, report, etc.
Displaying dates is almost always the job of the display layer, not the database. I would strongly suggest making this change at that level (report, app, etc.) rather than at the SQL level. Otherwise, you'll have issues with sorting, filtering, etc.
I think your problem is that you are trying to use an update. SQL updates change values, not data types. You are trying to create a different datatype, a char or varchar.
The field dbo.List.DtBirth is presumably a datetime, and your update does not change that. You could add another field, perhaps called DTBirthAsVarChar varchar(8), then update that based on the date field.
Update [TestFamily].dbo.List
set dbo.List.DTBirthAsVarChar = convert(
varchar(10), cast(dbo.List.DtBirth as
datetime ),112)
You also don't need both a convert and a cast in the same statement, they basically do the same thing.
Does SQLs built-in DateTime type has any merits over nvarchar type?
If it were you , which one would you use?
I need to store dates in my SQLServer database and I'm curious to know which one is better and why it is better.
I also want to know what happens if I for example store dates as string literals (I mean nvarchar )? Does it take longer to be searched? Or they are the same in terms of performance ?
And for the last question. How can I send a date from my c# application to the sql field of tye DateTime? Is it any different from the c#s DateTime ?
You're given a date datetype for a reason, why would you not use it?
What happens when you store "3/2/2012" in a text field? Is it March 2nd? Is it February 3rd?
Store the date in a date or datetime field, and do any formatting of the date after the fact.
EDIT
If you have to store dates like 1391/7/1, your choices are:
Assuming you're using SQL Server 2008 or greater, use the datetime2 data type; it allows dates earlier than 1753/01/01 (which is what datetime stops at).
Assuming you're using SQL Server 2005 or earlier, store the dates as Roman calendar dates, and then in your application, use date/time functions to convert the date and time to the Farsi calendar.
Use the correct datatype (date/datetime/datetime2 dependant on version and requirement for time component).
Advantages are more compact storage than storing as a string (especially nvarchar as this is double byte). Built in validation against invalid dates such as 30 February. Sorts correctly. Avoids the need to cast it back to the correct datatype anyway when using date functions on it.
If I'm storing a DateTime value, and I expect to perform date-based calculcations based on it, I'll use a DateTime.
Storing Dates as strings (varchars) introduces a variety of logistical issues, not the least of which is rendering the date in a proper format. Again, that bows in favor of DateTime.
I would go with the DateTime since you can use various functions on it directly.
string wouldn't be too much of a hassle but you will have to cast the data each time you want to do something with it.
There is no real performance variance while searching on both type of fields so going with DateTime is better than strings when working with date values.
you must realise the datetime datatype like other datatypes is provided for a reason and you should use the datatype that represents your data clearly.. Besides this you gain all the functionalities/operations that are special to the datetime datatype..
One of the biggest gains is correct sorting of data which will not be possible directly if you use nvarchar as your datatype.. Even if you think you dont need sorting right now there will be a time in the future where this will be useful.
Also date validation is something that you will benefit from. There is no confusion of the dateformat stored i.e dd/mm or mm/dd etc..
There is lot discussed about the subject. There is good post on the SQLCentral forum about this particular subject DateTime or nvarchar.
In short, nvarchar is twice as longer as datetime, so it takes more space and on the long range, any action affecting it will be slower. You will have some validation issues and many more.
In my current solution, I am converting a DateTime value, "Time" in my database using CONVERT so it displays in a ##:##AM/PM format, and I realize that CONVERT just takes whatever datatype and turns it into a VarChar, or a String once its in C#. This is making my sort work incorrectly in my Gridview. I am sorting the columns in my DataSet returned from my stored procedure. However it isnt sorting by AM/PM since its a string literal, and not a DateTime.
What is the best way to sort Time values? Should I use a different datatype, like TIME in my database? Different CONVERT command? I'm stumped! I can't use a 24 hour format, that's the only restriction. Thanks!
A couple of thoughts:
Could you use AM 01:23 / PM 01:23 format - this would sort well.
If you can return the times from the database in DATETIME format, but with the date set to some 'constant date' (e.g. 2000-01-01 hh:mm), you could almost certainly put a format string on the GridView column to display just the time, whilst still enabling sorting by the underlying value.
I use ticks: http://www.codeproject.com/KB/database/DateTimeToTicks.aspx
Or (if possible) DateTime - and handle it in my grid.
You can add an additional column with the date/converted date which is hidden in you gui but used to sort.
I'm supporting an existing application written by another developer and I have a question as to whether the choices the data type the developer chose to store dates is affecting the performance of certain queries.
Relevant information: The application makes heavy use of a "Business Date" field in one of our tables. The data type for this business date is nvarchar(10) rather than a datetime data type. The format of the dates is "MM/DD/YYYY", so Christmas 2007 is stored as "12/25/2007".
Long story short, we have some heavy duty queries that run once a week and are taking a very long time to execute.
I'm re-writing this application from the ground up, but since I'm looking at this, I want to know if there is a performance difference between using the datetime data type compared to storing dates as they are in the current database.
You will both save disk-space and increase performance if you use datetime instead of nvarchar(10).
If you use the date-fields to do date-calculation (DATEADD etc) you will see a massive increase in query-execution-speed, because the fields do not need to be converted to datetime at runtime.
Operations over DATETIMEs are faster than over VARCHARs converted to DATETIMEs.
If your dates appear anywhere but in SELECT clause (like, you add them, DATEDIFF them, search for them in WHERE clause etc), then you should keep them in internal format.
There are a lot of reasons you should actually use DateTime rather than a varchar to store a date. Performance is one... but i would be concerned about queries like this:
SELECT *
FROM Table
WHERE DateField > '12/25/2007'
giving you the wrong results.
I cannot back this up with numbers, but the datetime-type should be a lot faster, since it can easily be compared, unlike the varchar. In my opinion, it is also worth a shot to look into UNIX timestamps as your data type.
I believe from an architectural perspective a Datetime would be a more efficient data type as it would be stored as a two 4-byte integers, whereas your nvarchar(10) will be stored as up to 22 bytes (two times the number of characters entered + 2 bytes.). Therefore potentially more than double the amount of storage space is required now in comparison to using a Datetime.
This of course has possible implications for indexing, as the smaller the data item, the more records you can fit on an index data page. This in turn produces a smaller index which is of course quicker to traverse and therefore will return results faster.
In summary, Datetime is the way to go.
The date filtering in the nvarchar field is not easy possible, as the data in the index is sorted lexicographically which doesn't match the sorting you would expect for the date. It's the problem with the date format "mm/dd/yyyy". That means "12/25/2007" will be after "12/01/2008" in a nvarchar index, but that's not what you want. "yyyy/mm/dd" would have been fine.
So, you should use a date field and convert the string values to date. You will surely get a big performance boost. That's if you can change the table schema.
Yes. datetime will be far more efficient for date calculations than varchar or nvarchar (why nvarchar - there's no way you've got real unicode in there, right?). Plus strings can be invalid and misinterpreted.
If you are only using the date part, your system may have a smaller date-only version of datetime.
In addition, if you are just doing joins and certain types of operations (>/</= comparisions but not datediff), a date "id" column which is actually an int of the form yyyymmdd is commonly used in datawarehouses. This does allow "invalid" dates, unfortunately, but it also allows more obvious reserved, "special", dates, whereas in datetime, you might use NULL of 1/1/1900 or something. Integrity is usually enforced through a foerign key constraint to a date "dimension."
Seeing that you tagged the question as "sql server", I'm assuming you are using some version of SQL Server, so I recommend that you look at either using datetime or smalldatetime. In addition, in SQL Server 2008, you have a date type as well as a datetime2 with a much larger range. Check out this link which gives some details
One other problem with using varchar (or any other string datatype) is that the data likely contains invalid dates as they are not automatically validated on entry. If you try to chang e the filed to a datetime field, you amay have conversion problems wher people have added dates such as ASAP, Unknown, 1/32/2009, etc. You willneed to check for dates that won't convert using the handy isdate function and either fix or null them out before you try to chnge the data type.
Likely you also have a lot of code that converts the varchar type to date datatype on the fly so that you can do date math as well. All that code will also need to be fixed.
Chances are the datetime type is both more compact and faster, but more importantly using DATETIMES to store a date and time is a better architecture choice. You're less likely to run into weird problems looking for records between a certain date range and most database libraries will map them to your languages Date type, so the code is much cleaner, which is really much more important in the long run.
Even if it were slower, you'd spend more time debugging the strings-as-dates than all your users will ever see in savings combined.