You should use an appropriate DateTime
type in your schema. Do not use strings to represent Date
s or DateTime
s or Time
s, numbers, or anything else that is not a native string.
MySql allows for the following schema types:
DATE
TIME
DATETIME
TIMESTAMP
YEAR
In this case the most appropriate one would be DATETIME
. This aligns with the .net type System.DateTime
. If you are using ADO.NET then you should be using parameters in your queries. Example:
using(MySqlCommand m = new MySqlCommand("INSERT INTO table (sendDate) VALUES (@sendDate)"))
{
m.Parameters.Add("@sendDate", MySqlDbType.DateTime).Value = myObj.SendDate;
// rest of code
}
Batch Insert
You do not have to run one insert statement at a time. You can easily create one statement with multiple tuples that you want to insert. Here is sample c# code that does that with 1 column. You can easily extend this with multiple values per tuple.
var sql = "INSERT INTO table (sendDate) VALUES (";
var parameters = input.Select((queue, i) => new MySqlParameter("@sendDate" + i.ToString(), MySqlDbType.DateTime)).ToArray();
sql += string.Join("), (", parameters.Select(_ => _.ParameterName)) + ")";
for (int i = 0; i < parameters.Length; i++)
{
parameters[i].Value = input[i].SendDate;
}
using(var connection = new MySqlConnection(connectionString))
using(var command = new MySqlCommand(sql, connection))
{
command.Parameters.AddRange(parameters);
connection.Open();
command.ExecuteScalar();
}
When to convert?
The code stack should always convert a DateTime
to a string
as late as possible up the call stack, generally in the Presentation Layer (at the point a Human has to read it). The reverse is also true, a string
input should be converted to a DateTime
as early as possible going down the call stack (so again, in the presentation layer).
Why not varchar for Dates?
If you are wondering why you should not store DateTime
as a string
see this previous answer: When to use VARCHAR and DATE/DATETIME. I'll quote the important stuff:
Some of the disadvantages of the VARCHAR version:
- You can't easily add / subtract days to the VARCHAR version.
- It is harder to extract just month / year.
- There is nothing stopping you putting non-date data in the VARCHAR column in the database.
- The VARCHAR version is culture specific.
- You can't easily sort the dates.
- It is difficult to change the format if you want to later.
- It is unconventional, which will make it harder for other developers to understand.
- In many environments, using VARCHAR will use more storage space. This may not matter for small amounts of data, but in commercial environments with millions of rows of data this might well make a big difference.
Time Zones and Values
Do not forget about time zones if this is applicable to your application. It is recommended to always store a DateTime
UTC value in the database instead of a local timezone value. The UTC value can then be sent to the presentation layer where the presentation layer is responsible for applying the local time zone to the value (optional). Some UI frameworks have built in mechanisms for doing this in the DateTime
controls. Again, the reverse is also true, have the presentation layer convert any input to a UTC DateTime
value and send that back down the call stack to the server.