The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I am on one of those do something projects just keep the brain from rotting. I decided to look in to using a Database for stock control (trilling I know!) for the reason I have never really used a Database in programming before. I would an opinion of the best way to do it, either create the Database in C# and go from there, or import a fleshed out Access database...I have read conflicting opions for both. I am guessing that the database I need to edit and update has already been created and this is really a 'better' way of dealing with it. I looked down the list of available articles and none of them really helps. Ideas any one?
As someone who is a trained DBA I always prefer to design within the database management tools themselves and just use .Net to read,write,insert and update.
The nice thing about Entity Framework is that it allows you to do this via .Net/Visual Studio.
If I was in your position and knew nothing about the database tools that come bundled with the database engine I was going to use I would go for something like Entity Framework as there is no need to know everything needed to be a DBA.
“That which can be asserted without evidence, can be dismissed without evidence.”
I have once created a C++/MFC database application (the first and only one) using an empty db file as template created with Access. Because it was my first one it was a good idea to use Access to create the database. You will have it ready quickly, Access provides necessary integrity checks, and you can use it with Access to play around with some data. I suggest to do this even when deciding to create the database programmatically because it can be used as reference file and you will become more familiar with Access database files.
The above mentioned application has become many updates meanwhile which includes database changings. So I had to write all those functions which are used to create, change, delete, and move tables, fields and queries to update existing database files. The current development version is now able to create the file itself and I'm going to use this with the next release.
The first parts that I have removed from the template were the stored queries because they changed most frequently (not only by db design changings but also by optimising them).
Because you have never used databases programmatically before, I suggest to do it in a smiliar way. If you have the time and interest you can still switch over to a programmatically created file.
Personally, I'd avoid Access - for a "real world" stock control system you want a multiuser DB from day 1, and Access is very poor at that.
I'd suggest that you grab a free copy of SQL Server Express from MS, and use that instead. It also gives you Sql Server Management Studio (SSMS) which lets you do a lot more with the DB than VS does (and in a more "natural" way as well).
Doing the DB design is complicated, but well worth while - it teaches you a lot more about databases that trying to pick up a ready-made DB and trying to work out why it is the way it is, and if that really works for your exact situation.
If you look in your C# book (I'm sure you had one at some point, or am I imagining that?) it's almost certainly got a couple of chapters on DB's which will be worth reading before you get into any actual code or design.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Access has a bad reputation among developers, but it actually works perfectly fine for some situations where you don't want to have to install sql server, or where portability is desired. The only time I would warn against using Access is if your application will be handling more than a few concurrent users. If it's a single user app, it will work just fine.
0: sql compact (portable, but doesn't allow views)
1: sql server as a cloud service (such as Azure) (portability becomes a non-issue, but requires an internet connection)
2: sqllite (never used it, but also a single-file format)
...or, you could write the application to support multiple database types using oledb objects. This is what we do here...customers can use either Access or SQL Server depending on their needs. I'd still stick with Access for the design and query building. (my preference when working with Access is actually using Access 2003 as I hate the interface for the newer versions. Good luck!
Actually I'm going to bitch at you for using the wrong forum, the DB forums is perfect for this type of discussion!
It should depend on your goals, if you want to get into database and LOB development then use SQL Server and SSMS, it is the tool used by many departmental and SME shops.
Enterprise tend to use Oracle or what I call the pig iron databases, monsters that need a DBA to set up and run. Read years of experience needed to use properly.
Access is the other end of the scale and should be avoided like the plague.
I despise EF, too much of a black box and leaves junior developers with limited knowledge of data structures and TSQL. Having said that I have 2 tools DBops, a minimalist DAL and ClassBuilder a code generator for all the grunt work that EF does. The difference is I wrote the bloody things, I know how and why they work and can instruct juniors in its use in 15 minutes. I also encourage others in the team to contribute and smack them if they over engineer .
Never underestimate the power of human stupidity
Forgive me - but I'm not going to answer the question you asked - because code first vs. database first is (IMHO) immaterial.
You'll find your own preference, or your circumstances (such as a pre-existing database you have to work with), will dictate what you do. (Also, personally, I'm old school - I create my C# classes, and my Data Definition Language scripts - CREATE TABLE ... - at the same time. I like having precise control of my schema, foreign key constraints, indexes, primary keys, etc. AND I like being the author of my POCOs).
If you're new to using databases, there's a chance you're new to data modelling in the relational world. Understanding what makes a good (i.e. easy to understand, reliable and efficient in time and size) schema is far more important than how you translate between database objects and programming language objects.