First of all, Linq-to-SQL is for Microsoft SQL Server only - so in your case, that option is out the window right away.
Next, I guess you really need to decide how tricky and how complex your data access will be.
If you're mostly dealing with a few tables, each containing a couple of columns, and you need to read and write a few bits of information back and forth, then you're probably best off with standard, straight up ADO.NET (things like the ADO.NET connection and command object to execute SQL queries). In this scenario, it's up to you to handle all "translation" between the relational model (the rows and columns in your database), and the objects you have in your app - it's a bit of gruntwork and a bit of repetitive coding at times - but it works, it's fairly easy for simple scenarios, and gives you the best foundation for understanding ADO.NET's inner workings (if you're fairly new to it).
The ADO.NET Entity Framework and Linq-to-Entities is quite a different beast - and quite a bit more complex. It really shines when you have very large apps, with dozens or hundreds of tables in your database, a big and possible complex business object model in your app, and you need to support all sort of backends (SQL Server, Oracle, Postgres etc.). The EF allows you to define the mappings between the objects (your "Customer" class with its properties) and the relational storage in the database (your "Customers" table with its columns) in a designer, and EF will handle a lot of the grunt work of mapping between tables and your domain objects for you - but it's a lot more to learn, for sure.
So in your case, with a fairly simple app, I'd definitely recommend using just plain old ADO.NET for now, to get to know the ropes and get a feeling for how it works. I don't think going the EF route is worth the trouble and the learning curve in your case.
Marc