Right now all I did was use the Dataset designer and dragged tables into it from the Database Explorer. It works (for what I need anyway) but it feels like it's a misuse of Datasets. (Actually I'm not really sure how to use Datasets or what the intended usage is, I was planning on using LINQ2SQL to interact with the DB)
Is this ok? I only need it for the designer view and it's a very simple DB layout (just 4 tables). I'm sure there's other tools out there, but is there anything integrated into VS Express that I should be using instead?
You download MS SQL Express with the SQL Studio Management Studio Express. Only in the Studio Express can you connect to the server, select the database, open the database diagrams and edit diagrams.
Then, you can drag and drop the entire set of Tables in to Linq to SQL. Entity Framework is nice, but I have yet to get it to render my tables well yet. I would stick to Linq to SQL until they release another upgrade to EF (easier for you).
You say it works, and you want just want to make a diagram, so go with it. You should make sure it doesn't build the generated code file, however, as it could cause bloat in your final product.
If you're not going to use it for code and it provides adequate output for you, what does it matter if it's a "misuse"? I know people who used Excel to design documents because it was easier to line things up that way. I would use Word, and it's clearly not Excel's stated main purpose, but does it mean using Excel was wrong?
Related
I just installed and imported my database in Visual Studio , All I want to see is schema to get a quick relation of among different tables , I was hoping if I could get a way to do the same in SQL server just like it can be done with my sql reverse engineering
I use Azure data studio (the extension is buggy ), I also have Sql server manangement studio , I also visual studio and selected database management pack where SSDT was included and now I simply imported the database which I want schema for
SSMS has some rudimentary diagram tools to pull in objects and see any relations that exist. Something to watch for is that if you add any relations or modify anything other than the layout on that diagram, you actually change the database itself.
There are some free/cheap ERD apps/sites that you may want to investigate and many will give you a script to run in SQL Server to extract the schema in a format they can use.
I'd recommend searching on ERD apps that can do database diagrams, but for a free option you may want to check out https://dbschema.com/ (there's a free/trial version) or https://dbdiagram.io as they can handle some simple ER diagrams. (note - no affiliation to either, just some examples/options)
You can't easily forward-engineer changes with it, but it can work to just see the relationships visually. If you're going to use ER diagrams regularly, a paid option will be much more helpful. There are a lot of options available, but for that sort of design work you probably want collaboration and the ability to push out changes to a live database from the ERD.
I am relatively new to sql server and we are using sql server 2014 version in my workplace. Why do we actually need this database diagram in sql server(using SSMS)?
A database diagram offers a visualization of the database structure, and that's it's best (and some will probably say only) advantage.
While it is possible to use the diagram to edit the tables, including renaming, adding / removing columns, setting keys and what not, These things are usually best handled using DDL code (of course, if you know what you are doing).
You can think of a database diagram as a WYSIWYG editor for the database schema, and just like most (if not all) WYSIWYG editors, it does have it's drawbacks.
That's correct for all SSMS designer windows.
In fact, every DBA I know claims that the SSMS designer windows should never be used for designing database objects, and one must always prefer using DDL directly. I can only say I completely agree with this statement.
I've just migrated from Access where I would "write" SQL constantly and quickly using their GUI layout. I'm very new to SQL Server and am puzzled why is there no query GUI in SQL Server. Is it just that much more powerful that a GUI wouldn't be able to address the majority of queries? Or is it like a purist thing where once one is no longer in watered down databases like Access that he or she should just know SQL well enough to write it on the fly. Or am wrong altogether, and there IS a graphical way that most programmers compose SQL?
Sorry for the umbrella question, but I think some theory here would help me understand the big picture better.
I think there is a Query Designer as part of Sql Server Management Studio: see for example SQL Server 2005 Management Studio Query Designer.
The SQL Server is a database server. That it self does not have any editor text or GUI. You can mange it from the console, or any dedicated software that might have or not a query designer.
The main difference between Access and SQL Server or any other database, is that the MS Access is application that store the data in a file, when You close "Access" anything can happen inside the database by it self, while you are using SQL Server it is alway on You only connect to it. That why access have build nice query, report form designers. The SQL Server has totally different job to do and does not need this. With SQL Server we have Sql Server Management Studio, whit serve to global management not only for table creation and query design, there is a lot of background staff going on right there for example user management, rights jobs.
So it is not that SQL Server does not have a query designer, You just don't use proper software to work with it. A power full application is SSMS that ChrisW presented.
Actually there is a GUI-Designer for Views and Queries. Just use the SQL Server Management Studio.
For Example on the "Views" right-click and choose "Add View...". The view GUI is looking very similar to the one in access.
AFAIK about MySQL. Earlier there was the MySQL suite of tools and now there is the MySQL Workbench.
Say what you may, but it's definitely a timesaver.
First off, I believe the query designer in SQL Server Management Studio is probably the equivalent of what you've used in Access. I'm not terribly well-versed in using Access except through code, but I think you can do what you want there (in query designer). I've never found it to be very flexible, so I always end up back in the code itself, but there you go.
My other answer is a little bit off topic (and posted at this point mostly for googlers), but if you're a developer (especially using SQL Server), it probably still applies: Linq to SQL in Visual Studio.
I've been developing against SQL Server databases for about 7 years now, and most of that time has been spent writing the SQL statements out by hand. Last year, I changed jobs and finally had an environment where the databases my programs used were local and didn't change structure. I finally had a good opportunity to begin using Linq!
Linq is an amazingly useful tool!!! I now use it for almost (not quite) all of my database interactions from code.
The basic gist is that you create a graphical database layout in a dbml file. This layout includes tables (or views) as objects and association (PK/FK relationships) as links between the objects. How you set up the associations determines whether that property is a single object or an entity set of that object. Imagine you've got the following:
TABLE (ORDERS) TABLE (CUSTOMERS)
-------------- ----------------
PrimKey
CustomerID --(FK)--> PrimKey
OrderDate CompanyName
Using Linq to SQL, when you run something like the following:
Using db as new DataBaseContext
Dim orders = (From iOrder In db.ORDERS Order By iOrder.Customer.CompanyName).ToList
End Using
You end up with a list of Order objects that each own its corresponding Customer object. You can set this up to have object hierarchies and it pretty much works like you'd expect.
Anyway, it's a fairly big topic and more to get into than is appropriate here, but suffice to say that I think it's a great technology to bridge graphical interaction with true, nitty-gritty code.
What are the option in terms of applications that help build SQL statements against a SQL Server database?
We have some users that need to build SQL statements, preferably through drag and dropping or linking up tables etc.., against a SQL Server databse who don't have any experience in this area.
Any Ideas?
Visual Studio 2008 / 2010 have this featue and works well. I mean LINQ to SQL or Entity Framework, but in bigger projects I dont prefer Entity Framework.
The Sql Query editor in sql server 2005 and above is very good for that sort of operation. I found that the combination of drag and drop columns with the sql instructions below helps non-sql developers learn a little about sql and tends to wean them off of the editor.
I actually just ran into this problem in my own project.
One option is to purchase a tool that does precisely what you're looking for. If you do something like that, you're more likely to get something that's full-featured, well-supported, and has a lot of nice bells and whistles to make your job easier.
However, as both Svisstack and george9170 pointed out, there are already tools within the Visual Studio development environment. Here is how I'm proceeding:
I use Microsoft SQL Server Management Studio's Diagram editor to perform the dragging and dropping of tables. This works fairly well, although it's a bit more cumbersome to work with than some of the tools I investigated. (For the record, the reason I didn't use the tools I investigated was the cost.)
Once I develop the tables in the diagram, I tell MSSMS to generate the tables.
I then use the Database Publisher (it comes with VS2008 and VS2010) and I connect with the database. Using LINQ to SQL, I let the magic work behind the scenes so that I can utilize the various objects which will interact with the database.
If I'm not explaining this well, check out the two links below. It should make things more clear.
Using Database Projects for Visual Studio
NerdDinner - An ASP.NET MVC tutorial, but with good information on LINQ to SQL.
By using LINQ to SQL (as described in the second link), your users should be able to build queries against the database fairly easily. It's not drag and drop, but it's very simple and straightforward.
First, I hope they are not doing their queries against a production database!
For regular non developers, try using excel, for these reasons:
1) most generic users might have it on their PC already.
2) drag and link tables. There is a little GUI for simple drag and link tables in there.
3) Support. When they get into trouble, they can e-mail me the file and I can see what they have so far. I'll end up writing views or procedures for them to use.
4) They can use the results data using familiar excel interface and functions, which helps since their SQL ability is so limited.
For developers these GUI tools are extremely limited in what you can do with your queries. I've never found one that can do UNIONs, derived tables, or CTEs. I'm not sure if any can even do OUTER JOINs. For simple tasks, they might be ok, but to switch back and forth all day would be a pain, so I just type them up.
You can use Access databases as well. They let you form your own queries by dragging and dropping in Access 2010. However, if you are looking for easy to access data without the worries of SQL syntax, you might want to look at using Ruby ActionViews. If you are talking about live editing of the entire database if the database is of any importance (you can easily delete or clear an entire database on accident), I would do it in pure SQL, or better yet, not do this at all. If you are using MySQL, you should look at the possibility of using phpmyadmin for maintaining your database. It is a web based tool that makes database administration easy and can help you form your queries.
So recently on a project I'm working on, we've been struggling to keep a solution's code base and the associated database schema in synch (Database = SQL Server 2008).
Database changes occur fairly regularly (adding columns, constraints, relationships, etc) and as a result it's not uncommon for people to do a 'Get Latest' from source control and
find that they also need to rebuild the database as well (and sometimes they forget to do the latter).
We're not using VSTS: Database Edition (DataDude) but the standard Visual Studio database project with a script (batch file) which tears down and recreates the database from T-SQL scripts. The solution is a .Net & ASP.net solution with LINQ to SQL underlying as the ORM.
Anyone have ideas on an approach to take (automated or not) which would keep everyone up to date with the latest database schema?
Continuous integration with MSBuild is an option, but only helps pick up any breaking changes committed, it doesn't really help in the scenario I highlighted above.
We are using Team Foundation Server, if that helps..
We try to work forward from the creation scripts.
i.e a change to the database is not authorised unless the script has been tested and checked into source control.
But this assumes that the database team is integrated with your app team which is usually not the case in a large project...
(I was tempted to answer this "with great difficulty")
EDIT: Tools won't help you if your process isn't right.
Ok although its not the entire solution, you should include an assertion in the Application code that links up to the database to assert the correct schema is being used, that way at least it becomes obvious, and you avoid silent bugs and people complaining that stuff went crazy all of the sudden.
As for the schema version, you could use some database specific functionality if available, but i personally prefer to declare a schema version table and keep the version number in there, that way its portable and can be checked with a simple select statement
have a look at DB Ghost - you can create a dbp using the scripter in seconds and then manage all your database code with the change manager. www.dbghost.com
This is exactly what DB Ghost was designed to handle.
We basically do things the way you are, with the generation script checked into source control as well. I'm the designated database master so all changes to the script itself are done through me. People send me scripts of the changes they have made, I update my master copy of the schema, run a generate scripts (SSMS) to produce the new DB script, and then check it in. I keep my copy of the code current with any changes that are being made elsewhere. We're a small shop so this works pretty well for us. I realize that it probably doesn't scale.
If you are not using Visual Studio Database Professional Edition, then you will need another tool that can break the database down into its elemental pieces so that they are managable and changeable in an easier manner.
I'd recommend seriously considering Redgate's SQL tools if you want to maintain sanity over all your database changes and updates.
SQL Packager
SQL Multi Script
SQL Refactor
Use a tool like RedGate SQL Compare to generate the change schema between any given version of the database. You can then check that file into source code control
Have a look at this question: dynamic patching of databases. I think it's similar enough to your problem to be helpful.
My solution to this problem is simple. Define everything as XML, and make sure that both the database, the ORM and the UI are generated from this XML, no exceptions. That way, you can use code generation tools to quickly regenerate the database creation script, which will alter your schema while (hopefully) preserving some data. It takes some effort to do, but the net result is well worth it.