March 14, 2020 at 12:09 am
A lot of people don't even know about it and a lot of people that have been spoiled by other things don't care for it but SQL Server "Diagrams" can do the basic stuff fairly well. It also does reverse engineering. I probably wouldn't use if for anything big but it comes in real handy for "logically related sections of tables" and does quickly allow you to see which tables have relationships with a given table.
MS tried to get rid of it but there was almost a march on RedMond when they first dropped it from SSMS 18. They DID bring it back, for which I'm thankful because I use it a fair bit.
--Jeff Moden
March 16, 2020 at 3:46 pm
IIRC, from the one time long ago I looked at SQL Diagrams, it is only a physical design, there is no separation of logical and physical. If you don't distinguish them anyway, then I guess you won't care about that. But, again, you'd be vastly better off finding the best tool you can afford (or free if you can't afford anything) that actually has a distinction between logical and physical models.
Put another way, if your early design sessions include a developer, you're very likely not doing it right because you're skipping the logical modeling, which is the most important part. Early discussion should be business data related only.
Converting a proper logical model to a physical is overall straightforward, generally well-handled by a junior DBA / data analyst (the tool will do the bulk of it for you). However, more expertise will be required to best denormalize and otherwise adjust the logical model to match physical conditions / restrictions, before the actual generation of the physical db from the model.
SQL DBA,SQL Server MVP(07, 08, 09) "Money can't buy you happiness." Maybe so, but it can make your unhappiness a LOT more comfortable!
March 16, 2020 at 7:15 pm
While I agree that a good logical design is essential and required before a physical design, I've found that the wrong people are frequently the wrong people to do so and you end up with logical designs based on 7 red lines ( https://www.youtube.com/watch?v=BKorP55Aqvg ) and a lot of "insert miracle here" boxes in it. I've also found that a lot of people don't like people that understand the physical side of things because the bring "reality" to the table which, of course, foils every one's management dreams. I've also found that a whole lot of people make schedules and allocate resources based only on the logical design.
--Jeff Moden
March 16, 2020 at 7:36 pm
It's very difficult for many people to split the logical and physical design. But, it's critical to a good design that you keep the two separate. Getting a developer involved who can't think on the logical side only is a sure-fire way to corrupt the logical design with physical aspects and considerations.
As to "miracle boxes", don't see how they could apply, since the logical model is only data and data relationships. Constraints will be defined, and keys may be defined, but those, again, are a straightforward implementation in a relational dbms, typically automatically computer generated.
Likewise, you couldn't base a schedule on only a logical design since you never build a logical design. Only the physical design, based on the logical design, is actually built, with the logical design adjusted to match what's best for the specific physical implementation chosen. For example, a SQL Server design may look very different from an Access design, but they can both be created from the same logical model.
SQL DBA,SQL Server MVP(07, 08, 09) "Money can't buy you happiness." Maybe so, but it can make your unhappiness a LOT more comfortable!
March 21, 2020 at 5:14 am
This was removed by the editor as SPAM
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply