这是从数据库中检索数据的最快捷有效的方法吗？

Question

Is this the fastest and efficient way to retrieve data from the database to the business logic layer?

public static DataTable Getdata(Guid companyId)
{
    DbCommand command = db.GetStoredProcCommand("dbo.P_GetData");
    db.AddInParameter(command, "@company_id", DbType.Guid, companyId);
    IDataReader reader = db.ExecuteReader(command);
    DataTable data = new DataTable();
    data.Load(reader, LoadOption.OverwriteChanges);
    reader.Close();
    return data;
}

Answer 1

According to nawfal's benchmarks:

• What is the fastest way to read data from a DbDataReader?

For some reason Fill() :

dataAdapter.Fill(dataSet);

Is faster than Load() :

dataTable.Load(dataReader);

For example, something like this might be 4-5x faster than what you have:

using (var da = new MySqlDataAdapter())
{
    using (da.SelectCommand = conn.CreateCommand())
    {
        da.SelectCommand.CommandText = query;
        DataSet ds = new DataSet();
        da.Fill(ds);
        return ds.Tables[0];
    }
}

See his answer for more details and benchmark times.

Answer 2

It Depends on your Requirement..

There are many ways to retrieve data from database.

In Ado.net datareader and data adapter can be use. And they both have its advantage.

you can also use Linq to sql

and check this Performance Comparison: Data Access Techniques

http://msdn.microsoft.com/en-us/library/ms978388.aspx

Regards.

Answer 3

Assuming that your logic layer requires a DataTable , and ignoring other coding issues and requirements, this is probably plenty fast.

Do you have reason to believe that it's too slow for your needs? If so, experiment with different approaches, and don't neglect:

• the logic used by the stored procedure running your query, and the plan it generates
• the amount of data that stored procedure is returning (do you need all of those columns?)
• the bandwidth of the intervening network, if any

Edit: If I were doing something like this, if I was working with a reasonably-sized data model, and if I had influence over the business layer, I'd use a persistence framework (like the Entity Framework ) rather than straight ADO.NET. I'd do this not for performance reasons, though - a persistence layer is more maintainable in the long run.