Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

version control example - database design

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    version control example - database design

    I am creating a small project to implement a simple version control system for information records, such as what would be present in a Wiki.

    One example of such a system that many of us are familiar with is Wikipedia (www.wikipedia.org). The goal of that website is to create a large record of human knowledge based on entries created and modified by the public. Anyone with an account can add or modify records on topics that interest them. The underlying belief is that continuous editing and expansion by the public tends to improve the quality and quantity of entries in the website.

    In order to minimize any potential damage from vandalism, Wikipedia uses a version control system that stores every version of every record entered into the system. For my terminology, a “record” represents an entry in Wikipedia (e.g., “United States Congress”) while a “version” of a record represents the value of that record at one time (e.g., an original description of Congress or a revised version of the original description of Congress). Wikipedia’s version control system stores the username of the person making the edit, as well as the time and date of the edit, and an editor’s comment for the edit, so the reasons and virtue of each edit can be assessed. The virtue of an edit is determined by comparing a current (edited) version of a record to the previous version of the same record to highlight the changes made by the editor. If those changes are beneficial, the edit is retained. Otherwise, the edits may be reversed so that an earlier version of the record becomes the current version once again. Quality control is performed by the general public and by people who sign up as moderators on certain topics and are notified when changes are made within those topics.

    Several design decisions remain to be made. First, should version control be implemented on a (table) record level or on a field level? In other words, if a table has two fields (e.g., A and B), would a simultaneous change to A and B represent two changes or one? For reasons that will become clear, I will be implementing simultaneous changes to multiple fields as a single edit.

    Second, a decision must be made on how to store the versioned records. Several choices are possible, but I selected the simplest approach for my purposes (which may not be the best performing approach). That approach stores all versions of each record in a single table rather than storing the “latest” versions of all records in one table and “older” versions in another table. The reasons for this decision will become clear later in this case study.

    Third, I wanted to maintain a record of how later record versions were derived from earlier record versions. For example, for a particular record (e.g., the story about Congress), I wanted to be able to ascertain that the current version might be version “D,” and that the history of versioning for this record was to go from “A” to “B” to “C” and finally to “D.” Alternatively, where versions were reverted, that should also be apparent. For example, another version history could be “A” to “B” to “C” to “A” to “D.” This history represents that edits “B” and “C” were reverted, and version “D” was subsequently created by modifying version “A.” This record can be maintained by storing an index to the preceding version in the editing sequence. Thus, “B” would have a preceding version index for “A.”

    Fourth, I wanted to maintain who made the edits, when they made them, and store any comments they offer about the reason for the edits.

    Finally, I wanted to maintain a record of whether the edits had been formally reviewed. Therefore, I added a Boolean flag to the record to indicate approval.

    Combining all these factors, I created a table with the following fields:
    1) record_id (for uniquely identifying a record, in the sense of the word described above (e.g., a description of Congress);
    2) version_id (for distinguishing between versions of a record – e.g., a second edit to the entry on Congress);
    3) parent_version_id (for identifying which version of the record preceded this version of the record in the editing sequence);
    4) approved_flag (for indicating that the edited record has been approved);
    5) editor_id (who made the edit to create this version of the record);
    6) editor_timedate (when the editor made the edit); and
    7) editor_comment (any explanation for the edit provided by the editor).

    The fields above are in addition to the content field (a character string). I also added an auto-increment field as the primary key for the table.

    In light of the design goals and trade-offs described, any comments or concerns would be appreciated.

    thanks
    Dave

    #2
    Re: version control example - database design

    Looking back at my posting, I noticed that there is a lot of talk about the design, but only a small mention of "please offer comments."

    That last part was the important part, though!

    Any comments would be appreciated!

    thanks
    Dave

    Comment

    Working...
    X