It is better not to think about these two components as inseparable. Even more, design patterns such as
repository[
^] add an extra layer, to separate business logic from data access. This is a good approach when you need to choose. Of course, as SA mentioned, if you want to use .NET a properly mature ADO.NET driver for that data store is a must. If you have Linq and EF driver, than it is even better - in some cases you will have only these.
And at this point forget tables and the relational model for a second.
Based on your comment you are collecting sensor data. What you haven't spoken about is the frequency: one reading per second, per minute or per hour make a huge difference. Is this continuous reading 7/24/365 or just for a short period? Can you afford batch inserts? If not, can the data store handle the continuous granular inserts in terms of performance. And finally: how big your database will grow (think also about your indexes, transaction logs, and so on)? How can you properly handle that size over time?
And you have to think about your analysis too, what kind of queries you need to issue.
As I see you want a time series database. Unfortunately, there are few dedicated TsDBs for Windows, even less with handy drivers.
You can also take NoSQL in consideration. Many of these implementations are enterprise grade solutions, even with extensive feature sets for free. If you collect 100 parameters per device, and the frequency is not too high, MongoDB or RavenDB for example can be a good choice.
Of course, you can use MySQL too. It is better in such a situation that SQL Server, as you have less resource intensive storage engines to choose from. But you can also think about low profile engines like SQLite. Low footprint, high performance. If you need to do the analysis logic in your application anyway, this is a good choice.