Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am in the process of writing an application which, among other functionality, generates MediaWiki documentation of an MSSQL database (objects, tables, table data).
My question is which document formats you prefer, or are required to produce. I have too many ideas to follow, so your answers should set my priorities ;)
(I know there are other documentation-related questions on SO, but they mostly deal with how to generate documentation (I know how to), and do not ask for specific doc types or platforms)
Edit:
Thanks for the comments. Actually I have table relations already, since I parse foreign keys. However full cross-reference may be a bit trickier ;)
However the question was meant to ask for the document types, such as Word, PDF, ODF, whatever. What are your professional requirements or preferences?
Update:
Overview of generated documentation
It sounds like you have already decided on a document format, which is HTML based on MediaWiki markup.
Also you should generate Entity-Relationship Diagrams which are useful additions to database documentation (though ERD's don't tell the whole story either).
Do you mean document organization, i.e. what headings and content should be included in each page?
Here are some suggestions:
Table Structure
Column names, data types, constraints
Meaning and usage of each column
Extra logical constraints in triggers and application code
Indexes defined
Relationships to other tables
Tables dependent on this one
Tables this one depends on
Notes on special or implicit relationships, that have no enforcement through database constraints
Usage of table
Usage in stored procedures
Usage in application code
Usage in views
Who has read and/or write access; SQL privileges of each user or role
There are other questions at StackOverflow that are very close to this one.
"How to document a database" is a very similar question to yours, since it's specifically about wiki documentation solutions.
"What are the best ways to understand an unfamiliar database" may give you some good tips, as you are creating documentation that would help someone in that situation.
"How do you document your database structure?" is related but not as closely, because it's about putting documentation into the metadata itself.
You might want to have a look at what the commerical vendors do regarding this. As Bill said, you certainly need an ER diagram. Commercial products to look at could include Embarcadero ER/Studio, Red-Gate SQL Doc, Power Designer and others.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am using redmine for project management and issue tracking.
I was looking at the database tables and the underlying structure and was wondering if anyone who is VERY experienced with database architecture can comment on the structure.
I am concerned that once there are many users and hundreds (or thousands) of projects (each project containing many issues, with each issue containing many messages, etc.), the database structure could possibly turn out to be a weak point.
How is the performance impacted by this design?
I would like to hear about the Pros/cons of how the tables are laid
out and how the data is separated or normalized, and whether or not
it might be worth re-structuring.
What would be the benefits of
separating the data out to more tables (with less columns per table)
The database structure looks typical for an issue/project tracking system. If you can come up with a better structure, I would be very interested in seeing it :).
What you have to remember is that applying normalisation rules are all fine and dandy but if you apply it too much then sometimes you may hit performance problems (and the dreaded de-normalisation hacks start to creep in). In other words, there's a balancing act to be done between some normalisation and hardcore (too much) normalisation.
You would have to have a good reason to re-structure that database model. For example, it could be that for some particular query the database design does not serve the answer in an efficient manner. You could then start asking yourself what other table(s) could be created that would hold the data that I need in an efficient manner for optimal query performance. Also you could ask yourself what other indexes could be in place which will allow for optimal performance.
The fact is that until you have the very high number of users and projects and issues in this database as you predict it is hard to answer those questions. Maybe you could generate the data for some fake users and projects and test out the database to backup your concerns? Remember the adage of Professor Donald Knuth: Premature optimization is the root of all evil.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What's the diference between using relational database and relational database-object(hybrid).
Im making an application of adverts. Using common relational database, i think I could make tables of each type of adverts: cars,technology,estates,employment, services, this is the way a I do it.But reading about relational database-object I found that you can create a type field in the database(Oracle) that allows you to encapsulate another fields and methods, so what if I make only a table of adverts, knowing that all adverts have fields in common like title, description,the date it publish, images, but I can add a field that encapsulate another objects that will be cars,technology, employment, and inside of each one encapsulate attributes to them like
cars(model,brand,price),
technology(state,price,accesories,dimensions)
emloyment(job,payment)
Well this is the idea, actually for every advert you can actually enlarged the functionality, making a database for each one.
My question is: what are the potencial problems using relational database-object?
What is the best option?
Most if not all, of the worst database designs of the last ten years have at their root tables built to an object model rather than fitted to a relational model.
OOP is a programming thang; its concept of combining behaviour and data together works well when building APIs, etc. But it sucks when it comes to persistence, leading to horribly large tables, lots of duplicated data and monstrously slow queries. I'm not saying that's inevitable but it is the way to bet.
So why does Oracle support Types in the database? Because there are advantages to defining complex data types with behaviour: XMLType is one such, and Oracle Spatial makes extensive use of objects. But these usages are limited to individual columns of regular relational tables. The intention is not, and never has been, that we use object tables to store all the data in the database.
By all means use Types in your Pl/SQL programming. I have done this extensively, and for the right use case they can be extremely effective. Just don't store your data in them.
The most significant difference is that Oracle's object-relational technology is rarely used.
Very few programmers or DBAs have significant experience with object-relational technology. Database tools do not support objects well, or at all. Oracle does not support the technology well - it's buggy and does not get updated frequently.
Of course, just because a feature is rare does not mean you should ignore it. There are cases where Oracle's object-relational features work very well. But if you're planing to build a significant part of your database using objects, you need to consider the loss of skills, technology, and support.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
There is so much conflicting and confusing advice all over the web about this. And I would like to settle this for myself and for any one who will be looking for such information in future.
Question is — Will Entity frame work work well with database that has tables with no Primary keys.
Detail : I have a database and it has lots of tables that don't have a PK specified. Call it bad design or whatever, but there is nothing I could do to change the schema now. I have to work with it. And we would like to use EF because we like MS and we work with MS tools all the time. We sleep much easier knowing MS will keep updating and supporting this EF, with its full attention in future. Okay here now is my burning question which I have researched excessively on this website and others. "Can I use EF in my project fully knowing that my DB has some tables that will never have PKs" . Part of the problem is we really want to use EF for ease of use and we being MSphiles.
I have heard lot of advice ranging from:
It wont work.
It can be made to work.
Not a big deal at all...
That's where it gets really sick. Please advise.
Well, it largely depends on how you intend to use it. Without a primary key, you can't have referential integrity. So, in effect you can't have automatic lookups of subtables and such.
You can do manual joins of tables, and that should work.. but that severely limits the functionality of EF.
But here's the thing, nothing we say can convince you. What will convince you is doing it yourself. Build a test database, and a test app. Setup your EF database. See if it works for you.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have a social networking system, and there are topics, tasks, questions, links, documents, videos and so on. I plan to put all of them to one table named posts, and there is one column name kind to identify. Is it a good design ? why ?
BTW:
1、I am using postgresql
2、I just think there are many repeated columns between them , for example: the title, the content, the created_at and the author
From your description it seems like all these domain objects have something in common. Otherwise you wouldn't even think about storing them in one table. Accidently or not what you have described is one of the techniques of mapping inheritance to relational model, called single table. The link above describes in detail other techniques and what are their pros and cons.
You can't index columns for which you want to perform search on it. Why do you want to put everything in the same table at the first place?
No. It limits these things to all having the same attributes. So if, for example, a "Link" needed a URL field, a topic, a task, a question, etc would all have to have one too.
It is NOT a good design with postgresql. Normalizing data in a relational database is very important.
You should consider using a NoSQL database system such as mongodb.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I have several SQL Server 2005 databases ranging from 20 – 600 tables in an application and no documentation. I am looking for a database diagramming tool that is smart enough to pick tables that seem to be related to one entity (e.g., tables related to Patient, tables related to Orders) or one functionality (e.g., Patient Management, Order Management) and show them separately instead of drawing the entire database.
In the past, I have seen tables related to one piece of functionality represented in one color in the ER diagrams. In a well designed database, perhaps there will be multiple schemas that group tables related to one functionality together. But as all these tables are in one schema, and I want a tool that is smart enough to perhaps suggest which tables should go together under one schema. It won’t be perfect but perhaps it is intelligent enough to examine which tables should go together (for example based on relationships between them or based on which tables seem to be accessed together in the stored procs).
The bottom line is that I want to understand the data-model as quickly as possible. A tool called Schema Spy ( http://schemaspy.sourceforge.net/ ) seem to be headed in the right direction, but I was wondering if anyone knew better/more comprehensive tools.
Thanks.
Have you tried Visio at all? While it does not satisfy everything you asked for it can reverse engineer a database and make very appealing diagrams with a little work.
I have never used it to understand an existing database, but I have used it to explain databases I have created.
You could have a look at wsSqlSrvDoc. It's a nice little tool that works with Sql Server extended properties and creates a MS Word document.
The print-out of all column properties (with foreign key relations) works out of the box. For further descriptions on each field you have to set up extended properties of those columns in Sql Server Management Studio.
The downside however is that it's not free (but quite afordable). And if you just need to create a documentation for a "not work in progress" DB that's more or less finished than it would be enough to use the free trial i'll guess.
This question is related to an older question, Link:A good database modeling tool?
From the answer to this question, e.g. fabFORCE.net dbDesigner might be what you are looking for.