Could you list db modeling tools you use on daily basis?

Question

Could you list db modeling tools you use on daily basis?

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

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 1

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

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

ScottPletcher SSC Guru Points: 101098 More actions · Answer 2

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) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 3

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

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

ScottPletcher SSC Guru Points: 101098 More actions · Answer 4

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) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".