I'm currently working on a SQL Server relational database which will be accessed through the Entity Framework. I have a couple of questions that I cannot seem to find proper answers to.
Please see my database model diagram:
1.
I'm not quite sure if the ProblemType implementation is the right way to go. As it has been set up now, both columns allow null values in ProblemType since it will either contain a ProblemTypeRoadID or a ProblemTypeVandalismID. So the question is really if it is possible to de-normalize the model by removing the ProblemType table and relate both ProblemTypeRoad and ProblemTypeVandalism in the ProblemDesc table?
2.
Looking at the Problem table you will find a column named HistoryIDs. This column should contain a comma-separated string with all the HistoryIDs related to a Problem. A HistoryID is essentially a ProblemDescID (since a ProblemDesc gets its IsHistory column set to true whenever it is updated) as the ProblemDesc is copied whenever changed.
My question is: what is the best way to add multiple ProblemDescIDs to the HistoryIDs column? If it was something like "1,5,7" it would be easy to find all the histories for a given ProblemDesc.
3.
Any other suggestions for the diagram is also very welcome :)
Thanks in advance!
EDIT: Please consider the revised diagram:
Now that you have given me some great suggestions for improvement, I have tried to implement most of your suggestions. ProblemType has been removed and ProblemHistory added. Changes have also been made to how WorkerComment and Media relate to their parent tables.
Would this implementation work?
Thanks!
You can remove the problemtype table, and just relate problemtyperoad and problemtypevandalism to the problemtype table with the problem type id
No, it shouldn't. You should have a table ProblemHistory with columns ProblemID and HistoryID with a row for each History.
It seems you can have a worker comment that relates to multiple problems. Should it be the other way around? Similarly for media and ProblemDescs. Can only one worker work on a problem? Also, MSSQL has a geography type that you can use instead of CoordinateLat and CoordinateLng.
Related
I have a problem creating a database (I am still learning). I need to create a database for a company that generates a report like the one in the image.
Report to reply
I have the tables created as follows, but I have a problem in the t_stack with the t_tracking_number.
DB model and Relationship
The part that I don´t know how to do, is create the t_stack table, to register an id_stack, an id_driver, and then insert many tracking_numbers. at this moment according to the image, I should register for every track_number, an id_stack and an id_driver.
If someone can give me an idea of how to do it, or if I must change whatever in the database it doesn't matter. Sorry if I didn't make myself clear, this is my first project and I want to do my best. Thank you.
You have to add in your t_stack table an id (ID_stack), identity increment as a PrimaryKey. Then you can have all tracking_numbers and combinations you need.
I am trying to figure out what the best way to design this database would be. Currently what I have works, but it requires me to hard-code values where I would like it to be dynamic in the future.
Here is my current database design:
As you can see, for both the Qualities and the PressSettingsSet tables, there are many columns that are hard-coded such as BlownInsert, Blowout, Temperature1, Temperature2, etc.
What I am trying to accomplish is to have these be dynamic. Each job will have these same settings, but I would like to allow the users to define these settings. Would it be best to create a table with just a name field and have a one-to-one relationship to another table with a value for the field and a relation to the Job Number?
I hope this makes sense, any help is appreciated. I can make a database diagram of how I think it should work if that is more helpful to what I am trying to convey. I think that what I have in mind will work, but it just seems like it will be creating a lot of extra rows in the database, so I wanted to see if there is possibly a better way.
Would it be best to create a table with just a name field and have a one-to-one relationship to another table with a value for the field and a relation to the Job Number?
That would be the simplest - you could expand that by adding data-effective fields or de-normalize it by putting it all in one table (with just a name and value field).
Are the values for the settings different per job? If so then yes a "key" table" with the name ans a one-to-many relationship to the value per job would be best.
My problem is simple:
I have a column referencing people, and among all those persons one and only one has a specific status. What is the best way to represent this in a PostgreSQL database?
My first idea was to create a column of booleans all equal to false but for the specific person. It means I somehow also need to check that there is only one true in the entire column. However, it does not seem optimal as it means having one more bit per column, and as there might be quite a number of lines, it will waste data.
Second solution is to create a second table to reference the person. However it means creating a table just with one line...
Do you have any other idea of how to solve this problem?
Thank you!
PostgreSQL has an inheritance system that may work well for a problem like this.
CREATE TABLE people (...);
CREATE TABLE special_person ( ) INHERITS (people);
You can select * from people to pull all of the records, while still adding exclusive columns to the special_person.
Creating a table with one entry, with a foreign key to the main table seems reasonable to me. Having to maintain a status when you only care about one value seems wasteful and comparatively difficult to maintain.
I want to store comment replies in database table.
I have a table to store comments:
comment_id comment_par_id, comment_from comment_text comment date ....
New comment has par_id=0 while the replies has par_id set to comment id to which it was replied.
The nesting is just one level. Reply to a reply also has the same parent id.
Is this the best way to store the replies?
I looked few articles that recommends to create a separate table to store the replies.
Then have a mapping column to point the comment in the main table.
Another alternate is to create a third table that stores the mapping like:
reply_id comment_id
Which is the best way?
No matter what, I only run a query to return the replies for a given comment.
And it is the most running query and must run fast as we have millions of rows in the comment table.
It's a one (comment) to many (replies) relationship, so you should use two tables, with the replies table foreign keyed to the comments table.
If I understand you right, you have an "original post" of some kind, with a set of replies? Similar to how StackOverflow works, with an initial question, with a set of answers? If that is the case, there are a few options. There is the option of using a single table that supports different "types" of records. This choice has the benefit of only requiring a single table, however it also has the drawback of more ambiguity. One has to know that multiple types of records are stored in such a table, making it more confusing.
A better alternative is to have multiple tables, for each "type" of record. This removes the ambiguity, while adding complexity. From a different perspective, different "types" of similar records often have different data, even if some of the data is the same. By using separate tables, it is easier to add distinct traits to each type of comment (original vs. reply), without having to resort to a variety of oddball ways of storing and referencing he extra "unique" data in a single-table system.
Since it is similar to StackOverflow, check out the Schema. Look at the Posts and Comments table.
http://sqlserverpedia.com/wiki/Understanding_the_StackOverflow_Database_Schema
I have a table that must reference another record, but of the same table. Here's an example:
Customer
********
ID
ManagerID (the ID of another customer)
...
I have a bad feeling about doing this. My other idea was to just have a separate table that just stored the relationship.
CustomerRelationship
***************
ID
CustomerID
ManagerID
I feel I may be over complicating such a trivial thing however, I would like to get some idea's on the best approach for this particular scenario?
Thanks.
There's nothing wrong about the first design. The second one, where you have an 'intermediate' table, is used for many-to-many relationships, which i don't think is yours.
BTW, that intermediate table wouldn't have and ID of its own.
Why do you have a "bad feeling" about this? It's perfectly acceptable for a table to reference its own primary key. Introducing a secondary table only increases the complexity of your queries and negatively impacts performance.
Can a Customer have multiple managers? If so, then you need a separate table.
Otherwise, a single table is fine.
You can use the first approach. See also Using Self-Joins
There's absolutely nothing wrong with the first approach, in fact Oracle has included the 'CONNECT BY' extension to SQL since at least version 6 which is intended to directly support this type of hierarchical structure (and possibly makes Oracle worth considering as your database if you are going to be doing a lot of this).
You'll need self-joins in databases which don't have something analogous, but that's also a perfectly fine and standard solution.
As a programmer I like the first approach. I like to have less number of tables. Here we are not even talking of normalization and why do we need more tables? That is just me.
Follow the KISS principle here: Keep it simple, (silly | stupid | stud | [whatever epithet starting with S you prefer]). Go with one table, unless you have a reason to need more.
Note that if the one-to-many/many-to-many relationship ends up being the case, you can extract the existing column into a table of its own, and fill in the new entries at that time.
The only reason I would ever recommend avoiding such self-referecing tables is that SQL Server does have a few spots where there are limitations with self-referencing tables.
For one, if you ever happen to come across the need for an indexed view, then you'd find out that if one of the tables used in a view definition is indeed self-referencing, you won't be able to create a clustered index on your view :-(
But apart from that - the design per se is sound and absolutely valid - go for it! I always like to keep things as simple as possible (but no simpler than that).
Marc