@dxdydz: This is a bit long, but I hope it helps you get a general idea of how working with databases works in Visual Studio / .NET.
When you're doing regular C/C++ development, you aren't really exposed to Visual Studio's database tools. They're a .NET thing. Open Visual Studio and create a .NET project in your poison of choice C#, VB.NET, F#, whateverand you will have a ton of database classes, frameworks, and built-in designers, etc. at your fingertips. Aside from the basic System.Data classes, all of them are more or less designed with abstracting away from the database (or at least 'raw' SQL) in mind and making working with the database more like working with code in the language you're using.
To make things easier to understand without having to practically learn a whole new language, I won't go into buzzwords, specific technology names, or details too much. With all these shiny tools, it is actually very much possible to create a database and all the necessary code to interact with it: retrieving, inserting, and modifying data, altering the schema (the 'design' or 'structure' if you will), exporting and importing data en masse, etc. without actually writing a single line of database code. The quality of the end result depends on the person using them, their motivation for using them, their expectations, and which of the tools they're using.
Anyway, with this 'abstracted' database approach, you mostly use various 'high-level' database classes (auto-generated or available out-of-the-box) to work with the data instead of fiddling with connections, SQL queries, parameters, etc. by hand. There's a good, a bad, and an ugly to this. LINQ is the good, the graphical SQL tools the bad, and "Code First" the ugly. (You can Google LINQ and Code First and briefly skim over the results to get an idea of what they are. Normally I hate people who say "You can Google," but it's actually a good idea and can give you a better idea than I can, and you can be familiar with these things in less than 5 minutes.)
Whether all of this a good thing or a bad thing generally speaking depends on how far you go with it. If you're reasonably familiar with the basics of database design and administration, you can use these conveniences as tools without using them as crutches. That's good, and you can create databases just as good as ones hand-coded in SQL in a lot less time and with considerably less effort. If you're all "I ain't care bout no databases let this here Visual Studio do all that," that's bad, and you are seriously a Visual Studio and/or anti-database fundie.
The graphical SQL tools that just do database design and other database tasks without being a part of .NET are the bad. This is the click-and-drool garbage I mentioned in my earlier post. It includes most database stuff in the Visual Studio Tools menu and any SQL auto-generated by basically anything (or at least the SQL auto-generated and output in a form you can look at). Especially bad is the auto-generated SQL in the Server Explorer's design mode. The FSTDT database was probably built from an exported SQL file using the Server Explorer's design mode and wizards, which are still pretty bad. (Visual Studio's database tools and language features were not as polished then as they are now, but I haven't played around with an old version of Visual Studio from that era of FSTDT to see just exactly what the situation was.) Either way, the whole VARCHAR/NVARCHAR fail was most likely a product of the click-and-drool database tools that deal with SQL and not the click-and-rule ones that are a part of the languages or integrate with them.
Code First is more of a paradigm / disease than an actual feature or tool, though it does generate databases for you from code that is written as if the database didn't even exist and you're retrieving and inserting data from thin air. (Who thought this was a good idea??) Unlike their other recent database stuff, I think "Code First" is an affront to all reason and could probably write a thesis on why it's fail. It's the ugly.
TL;DR: If it's a part of the .NET languages or integrates with them, it's good. If it's a graphical tool that's not part of them and deals with pure SQL only, it's bad. If it's Code First, it's ugly.
If this wasn't very useful or you have any more questions, I'm here :)
