George actually had the DB stuff we worked up last time we went through this. I have posted it at the Wiki, because I appear to be too stupid to figure out how to post it here. Go there, check it out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This schema doesn't support many users to one incident - this may not be a bad thing (only one user is assigned to any given incident, the rest can just query for incidents that they want to review) or no - what do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So does Cory want this instead of the idea of an "Assigned User" (replaced with "interested users" or some such) or in addition to the "assigned user"?
Basically, do you want to leave the "maintainingUserId" field in the table or take it out? I suppose we could drop that field and, in the join table we add a user role attribute to handle that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made changes to support threading of intel, and I think I corrected the ID issue. I sent those changes to Lee as I have not yet figured out how to load that stuff here or at the Wiki. As for the one incident, many users, I can make the change to support that, and then, if we choose only to implement 1 to 1, the model will still work, either by enforcing it in the app (which I don't like), or by changing the RI on the tables.
I'll send that stuff to Lee soon since I'm too lazy to figure it out right now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, as Cory has pointed out, there is no relationships made between incidents in this model - I think we might want to have the ability to record incident dependencies
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lee asked me to straighten you guys out. Not sure that's possible in one single post...but as for dependencies of incidents - I think there is no question that this is important.
I had suggested that we *might* want to re-think the data model. How about if I take a cut at what I think it should be, and then write up a brief description of the supported relationships.
Then we can have fun hacking that to shreds and saying, "That George sure is a dope."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the first run at the data model, we had a "comments" field available for each entity - in the second version it seems to be missing in most entities. I think a comments field is a handy thing to have, thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In our late night discussion on AIM just prior to my making these changes, you and I discussed the idea of abstracting comments off into a separate table. The advantage to doing this is that you could have a threaded series of comments if you want - although we might have to change the table slightly if we want that, adding some self-referential deal to the thing.
I then said to myself, "Self, that table will end up looking a lot like the Intel table." This caused a lightbulb to turn on....Comments ARE Intel, just without an associated file or other non-text thingy. So why not just store Comments in the table. I probably should write up a little blurb on the data model, and what it supports, but I wanted you guys to look at it and see if there are any glaring holes/errors before doing too much on that.
Let me know what you think about the threaded comments deal.
By the way, what is Hibernate?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah - right - I remember that now (I have this condition...). True indeed, Comments are intel. And the ability to support threaded comments is a good thing. I don't think it would make the code too much more complicated either. So, (not in the data model, in the app) - would intel be the only entity to support threaded comments? I mean, would you really need that for something like Company? I see the Company or User comments as more a "misc info" field, whereas Incident comments might be a "misc info on current status which might change over time" field. To keep the data model simple we don't need to make the distinction there, but it might make sense in the application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see now the error of my ways -- a "comment" is just an Intel record withouth much else in the record -- I was thinking that George wanted to use Intel to support comments, ie, ditching the comment column and just letting the Intel structure support comments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All intel would be "threadable" There's Cory's version control in that we could say...Here's the old screen shot, here's the new one..
My idea is that the thread would be down a single line. In other words, I could relate a piece of intel to only one parent record. A parent could have many children though....So you could end up with someone making a comment. Someone "replying" to that comment and one thread spawning from it (Replies to replies to replies) meanwhile, someone else could start a different thread from the same top level. Would that be ok?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aye - intel can be related to one parent record, but a record can have many related pieces of Intel. Sounds good to me. But, I didn't see a way to relate an intel record to another intel, so I am not sure how the model would support the "reply" to a comment (I could however be completely missing it, as it's a little late)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason I ask about the differing Id's is 'cause I have a BaseTO object (used from the previous code base) that all our transfer objects (or Value Objects) inherit from that contains an Id field - a scheme that makes the assumption that all entities have a single long (or int, or whatever) as a primary key. If there is a reason not to do this then cool, I'll yank it out and toss an Id field into all the entitiy TOs, but if not then I won't.
I have all the TOs we need to support this data model ready to check in.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, a given piece of Intel could belong to one and only one of each entity. That is, I could associate a file with Product A or Product B, but not both - is that ok? I think it is, but what do you fine folk think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This was also part of our late night discussion. Our thinking was, would we ever have a piece of intel that would be assigned to 2 entities, and be of a nature that any time the intel on one of the entities would change, it would change on ALL of the entities with which it was associated. If we think we want this, we can slip in an intersect-type table and move on.
The interface would be odd, I think..."OK, you just uploaded a screen shot (I am a mediumblob, too). Now, is there anything else you want to assign this to?" Hmmmm....
The alternative is that the user would have to add the same file or whatever several times. Multiple uploads, extra storage space. Hmmmm....(2nd time).
You guys tell me what you want. We could even add the table for now, but hide the functionality and decide later to expose it. I think I'd rather add the table at that time. It would not be hard to do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we should have one intel, and it should relate to at most one of any given entity. In the "normal" world, if we take a memo, or a screenshot, or whatever - it should relate to a product, or incident. In the "exception" world I suppose something *could* relate to more than one product, but I wouldn't think this would happen often. If it did, a user could, as George points out, simply upload the item twice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
George actually had the DB stuff we worked up last time we went through this. I have posted it at the Wiki, because I appear to be too stupid to figure out how to post it here. Go there, check it out.
This schema doesn't support many users to one incident - this may not be a bad thing (only one user is assigned to any given incident, the rest can just query for incidents that they want to review) or no - what do you think?
Cory wants one incident, many users.
So does Cory want this instead of the idea of an "Assigned User" (replaced with "interested users" or some such) or in addition to the "assigned user"?
Basically, do you want to leave the "maintainingUserId" field in the table or take it out? I suppose we could drop that field and, in the join table we add a user role attribute to handle that.
I made changes to support threading of intel, and I think I corrected the ID issue. I sent those changes to Lee as I have not yet figured out how to load that stuff here or at the Wiki. As for the one incident, many users, I can make the change to support that, and then, if we choose only to implement 1 to 1, the model will still work, either by enforcing it in the app (which I don't like), or by changing the RI on the tables.
I'll send that stuff to Lee soon since I'm too lazy to figure it out right now.
Ok, as Cory has pointed out, there is no relationships made between incidents in this model - I think we might want to have the ability to record incident dependencies
Roger that. There's not *might* to it. Can't we just have another many to many table? This thing is becoming more ed-like hour by hour.
I think I can lift some of the old graphics. Ha!
I meant to say "no" not "not" and couldn't seem to find an edit function.
So we want a "TaskDependencies" table - maybe using the existing roles table, or do we dream up a new "dependencyType" table?
Lee asked me to straighten you guys out. Not sure that's possible in one single post...but as for dependencies of incidents - I think there is no question that this is important.
I had suggested that we *might* want to re-think the data model. How about if I take a cut at what I think it should be, and then write up a brief description of the supported relationships.
Then we can have fun hacking that to shreds and saying, "That George sure is a dope."
In the first run at the data model, we had a "comments" field available for each entity - in the second version it seems to be missing in most entities. I think a comments field is a handy thing to have, thoughts?
In our late night discussion on AIM just prior to my making these changes, you and I discussed the idea of abstracting comments off into a separate table. The advantage to doing this is that you could have a threaded series of comments if you want - although we might have to change the table slightly if we want that, adding some self-referential deal to the thing.
I then said to myself, "Self, that table will end up looking a lot like the Intel table." This caused a lightbulb to turn on....Comments ARE Intel, just without an associated file or other non-text thingy. So why not just store Comments in the table. I probably should write up a little blurb on the data model, and what it supports, but I wanted you guys to look at it and see if there are any glaring holes/errors before doing too much on that.
Let me know what you think about the threaded comments deal.
By the way, what is Hibernate?
Ah - right - I remember that now (I have this condition...). True indeed, Comments are intel. And the ability to support threaded comments is a good thing. I don't think it would make the code too much more complicated either. So, (not in the data model, in the app) - would intel be the only entity to support threaded comments? I mean, would you really need that for something like Company? I see the Company or User comments as more a "misc info" field, whereas Incident comments might be a "misc info on current status which might change over time" field. To keep the data model simple we don't need to make the distinction there, but it might make sense in the application.
I see now the error of my ways -- a "comment" is just an Intel record withouth much else in the record -- I was thinking that George wanted to use Intel to support comments, ie, ditching the comment column and just letting the Intel structure support comments.
All intel would be "threadable" There's Cory's version control in that we could say...Here's the old screen shot, here's the new one..
My idea is that the thread would be down a single line. In other words, I could relate a piece of intel to only one parent record. A parent could have many children though....So you could end up with someone making a comment. Someone "replying" to that comment and one thread spawning from it (Replies to replies to replies) meanwhile, someone else could start a different thread from the same top level. Would that be ok?
Aye - intel can be related to one parent record, but a record can have many related pieces of Intel. Sounds good to me. But, I didn't see a way to relate an intel record to another intel, so I am not sure how the model would support the "reply" to a comment (I could however be completely missing it, as it's a little late)
Currently, the model does not support the relationship. I need to either add a column to the table, or a separate table. I'm noodling on that.
So, I couldna help but notice, some of the IDs are declared Integer, some as Long, Intel's ID is Char(10), why is that?
The reason I ask about the differing Id's is 'cause I have a BaseTO object (used from the previous code base) that all our transfer objects (or Value Objects) inherit from that contains an Id field - a scheme that makes the assumption that all entities have a single long (or int, or whatever) as a primary key. If there is a reason not to do this then cool, I'll yank it out and toss an Id field into all the entitiy TOs, but if not then I won't.
I have all the TOs we need to support this data model ready to check in.
It's because I did not pay attention when adding those fields. I will correct.
So, a given piece of Intel could belong to one and only one of each entity. That is, I could associate a file with Product A or Product B, but not both - is that ok? I think it is, but what do you fine folk think?
This was also part of our late night discussion. Our thinking was, would we ever have a piece of intel that would be assigned to 2 entities, and be of a nature that any time the intel on one of the entities would change, it would change on ALL of the entities with which it was associated. If we think we want this, we can slip in an intersect-type table and move on.
The interface would be odd, I think..."OK, you just uploaded a screen shot (I am a mediumblob, too). Now, is there anything else you want to assign this to?" Hmmmm....
The alternative is that the user would have to add the same file or whatever several times. Multiple uploads, extra storage space. Hmmmm....(2nd time).
You guys tell me what you want. We could even add the table for now, but hide the functionality and decide later to expose it. I think I'd rather add the table at that time. It would not be hard to do.
I think we should have one intel, and it should relate to at most one of any given entity. In the "normal" world, if we take a memo, or a screenshot, or whatever - it should relate to a product, or incident. In the "exception" world I suppose something *could* relate to more than one product, but I wouldn't think this would happen often. If it did, a user could, as George points out, simply upload the item twice.
Wiki wiki.
Intel & Comments, sounds like we're bordering on version control -- it's just a few more steps to adding a check-in date and a diff utility ;).
A) Do we need types of intel if we're going to have to identify a comment.
B) If Comment = Intel -- then I suppose Intel will have a one-to-many/many-to-one relationship with itself?
Any comment having any number of responses/comments any number of comments having one parent.
I'm not a relationship guy so that may sound all cracked out.