2

I am working on a database management application and I store the database objects (Tables, views, triggers, etc...) in a tree and I need some extra insight in re-thinking the features of the tree regarding to some new feature I have started to implement.

The philosophy of the application is to have a "Solution", this Solution contains more "Projects", the Project contains a "Major version", and all the database objects (such as listed above) are the children of the "Major Version" tree node.

In reality this looks like:

The tree I have right now

So, as you can see the tree below the version contains a little bit more than just the tables, views, etc, since the application allows you to create also diagrams with the database objects, generates SQL code and documentation too...

Now, comes the dilemma:

I have started to implement versioning support for the application, this in fact means that after the Release of "Ver: 1.0" there will be another tree entry below this, named "Ver: 2.0" which will basically have the same elements as you see right now which totally makes sense, since the user will need to start from V1.0. (However after a release, all the objects in V1.0 will be "locked" and the user will need to specifically unlock them if he wants to work on them (thus resulting version 1.1))

But I have a concern related to the positioning of non-database elements in the tree (Diagrams, Documentation, Code) since versioning for them makes no sense.

I basically have to approaches in my mind to attack this:

  1. reorganize the tree, in a way that I "pull up" these elements one level, so that they are at the level of "Ver: 1.0" bu this might cause another issue, since the diagrams (for example) are created with the elements found in the version they are placed, and so is the code generated based on the elements of the version, so pulling them up might cause confusion.

  2. leave the tree as it is

what do you think would be the best approach for this?

Improve this question
3
  • It's a bit tricky trying to determine the actual question you're asking here. Are you asking if you should duplicate full branches in a tree if you're creating a new version? It's not really clear how to answer this question. Perhaps it's a very localized issue just to your situation?
    – JonW ♦
    Jul 6, 2012 at 9:01
  • @JonW: I am trying to determine which is less confusing for the users: To have a lot of items (all of them, tables, views, diagrams, code, ...) shown duplicated in the tree or to have less item duplication (only for those that are effected by versioning: Table, view, ...) and a common gathering place for the other items (Diagram, Code, Documentation), but in that case to have an extra selection somewhere else to achieve the correct functionality for the latter.
    – Ferenc Deak
    Jul 6, 2012 at 10:35
  • So are you saying that, under no circumstance there will be a need for versioning of documentation, diagrams, and code? Or should be flexibility exist? If you put diagrams at the same level as Ver:1.0, and there are multiple diagrams generated from many versions, are you thinking of automatically adding suffix at the end? (e.g. Diagram1_v1.0, Diagram2_v1.0, Diagram1_v3.0, Diagram1_v4.0, etc)
    – Jung Lee
    Jul 12, 2012 at 18:50

1 Answer 1

Reset to default
1

But I have a concern related to the positioning of non-database elements in the tree (Diagrams, Documentation, Code) since versioning for them makes no sense.

When you change anything in a database, the diagram also changes. Even if it's a tiny little bit switching type on a column from INT to BIGINT. And since the diagram changes, the documentation should also be changed accordingly. Otherwise the documentation doesn't belong within the database and could be published somewhere else (web, DVD, printed manual, Google Docs,...). Code, as in my interpertation procedures, functions and triggers also changes when you make database changes, thus Code should also be under version control - in your screenshot.

It puzzles me that you feel a need to have every version visible, and presumably also idle, like the way you describe your design. I have never seen this kind of previous version representation apart from the version control tool itself (read Subversion). I think you need to step back and rethink the idea of previous versioning, and make use of available and free versioning tools instead of current suggestion.

Always ask yourself what problem you are trying to solve.

Improve this answer
4
  • 1
    Hi, thanks for reply, it is useful :) Now some explanation: the "previous" versions should be all visible because after a deployment (of v1.0) (this is what the tool does... deploys databases) the user might consider that v1.0 is done, so he might release to v2.0. But if after some time they discover a bug in v1.0 they will need to modify v1.0 (thus obtaining v1.1) and deploy the changes to all the locations the v1.0 was deployed. They might not want to deploy v2.0 since it might contain too much irrelevant changes. This is why all the versions should be visible, even if idle.
    – Ferenc Deak
    Sep 28, 2012 at 6:50
  • @fritzone Ahh, I see. It's kind of different branches of the same code base then. This is also possible in a real subversion tool, especially useful having a large devvelopment team. A smaller group works on a particular part of the code, and another group in another part of the code. When they are all done with development, they merge their code with the original code. That way developers don't interfear with each other during development. Nica to know my answer was useful. I've been struggling with this question for over a month before taking a shot at it :-)
    – Benny Skogberg
    Sep 28, 2012 at 7:03
  • Yes, you're right, that is the final purpose of it. This tool is more or less is supposed to be to be managed by 1 person tool, since in our experience the database deployment is (should be) managed usually by a small team/1 person, in order to not to get a very chaotic and hectic process. And the purpose of this tool is just to get rid of all the hundreds of small SQL scripts that usually go along with a database deployment, and instead have everything in one place with a GUI and in just a few clicks you have your DB deployed in various places. This way there is more control over the process.
    – Ferenc Deak
    Sep 28, 2012 at 9:28
  • @fritzone Sounds very insightful. There is always a problem when you have different versions at differnt customers. In my previous position we developed procedures from SQL Server 2008 R2 and deployed to all customers. Even though one customer still were on SQL Server 2000, with the effect that they didn't get everything. Scary on every deployment "Will it stop working - this time?"
    – Benny Skogberg
    Sep 28, 2012 at 10:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.