4 ms·

It is particularly difficult in a collaborative application with 'hard' links between records. For example, consider this scenario: (1) Sally deletes an emplo

• rangibaby 13y ago
  Intuitively, I would expect it to restore both the department and employee, or throw it into a "Bob and Sally: Please fix this conflict" kind of box.
  • NovaS1X 13y ago
    I'd expect it to depend on the permissions of the user restoring or deleting the groups. Under complete presumption: Bob is an HR member while Sally is a Manager. Why? The ability to manage entire groups should be left to people higher up in the administration chain where individual users should be delegated to HR or other staff. Bob should have permissions to manage users but not groups. Sally should have permissions to manage both. If Bob deletes a user, then Sally deletes the group, there should be no reason that Bob should be able to anything outside his domain. The group should not be restored and Bob should be given a clear, 'plain English' reason why he can't do such an action. If both Sally and Bob are managers of a group and said situation occurs, no group should be restored when Bob restores a user. Only a readable error message should occur. In fact no data to be restored should be there in the first place unless it has been backed up or cached. What is a possible solution to this logic? 1.) You could implement an optional backup system. All deletes are final in the context of the action. Think of a common tree structure: if no main branch is there to support a twig then no twig can hang. No restores via users can be performed until the group has been restored. The deleted data could be stored in a cache until certain parameters are met; once these are met the data is deleted (IE: Recycle Bin) 2.) Users could be restored belonging to a default group. If a recently deleted member of a recently deleted group needs to be restored, they could be assigned to a default 'holding' group or other similar group with restricted permissions. This retains all specific user data which is not lost and by default the user will not be given extraneous or extra permissions. They can then be assigned to an appropriate group. 3.) Removing a group does not affect users within it. This is the opposite of a tree structure. This is analogous to Linux group and user permissions. A group can be assigned to users so they can access a resource. They are not interconnected in any way other than their usage to control permissions. Users can be removed and restored at will and so can groups. No conflicts of hierarchy are incurred. In summary, restoring an individual resource should never restore the controlling body without given consent. This would create a lot of problems if it did.
• dirtyaura 13y ago
  Yes, it gets complex fast in collaborative setting. To my understanding, there are two robust approaches to collaborative editing: - git-style 3-way-merge - Google Wave -style operational transform If somebody is experienced on the topic, I'd love to learn more about different approaches. Also, it would be awesome to have these as an open source DB projects (well, we have git) or even offered as IaaS.
• hueving 13y ago
  >(1) Sally deletes an employee record >(2) Bob deletes that employee's department I would argue that a good design would actually prevent you from deleting important records like these. i.e. when Bob clicks delete, it just marks the object as deleted and it stops showing up in reports/interfaces. Then maybe you have something clean it up 90 days later or something.
  • ajuc 13y ago
    Yes. This is pattern I've seen in both companies I worked for, and it makes so much sense. Similairly you don't make table ARTICLES with column AMOUNT and KIND. You make table CHANGES with DIFFERENCE and KIND, and only ever add rows to that table (possibly with negative DIFFERENCE).
    • pc86 13y ago
      Sorry I don’t really understand what you’re trying to say here. Could you expand on the differences in data between the two tables, please?
      • Xlythe 13y ago
        In the first case, you only know the AMOUNT. You can't undo transactions because you only have 1 object stored, the total amount. If you store DIFFERENCE, then you'll have a table of every transaction and can undo them individually. The cost is having to sum the table whenever you want to know the amount (which is usually worth the flexibility).
        • ajuc 13y ago
          Regarding the performance - you can add triggers writing to additional table with a sum, or maintain that table in the code that adds rows, or calculate it each time you want to know the sum.
      • rehack 13y ago
        This is what I understood (s)he means Scenario: Laptop's price is initially $800 and then increases to $850 before dropping to $825 Design 1: with columns Amount and Kind will just have a single row which will get modified with the latest value Design 2: Will have 3 rows in the above case Difference | Kind | Time stamp 800 | 'Laptop' | ts 1 +50 | 'Laptop' | ts 2 -25 | 'Laptop' | ts 3 So this latter design has 'undo' builtin edit: formating
• troym 13y ago
  (3a) No, because your data model never allows physical deletes. (3b) And because you modeled up to 6NF with temporal keys, you've got the record from (1) and (2) and you know at what times they were related.
• antimagic 13y ago
  If Bob truly has the authority to decide that the entire department can be deleted from the database, and if the employee record really does have a dependency on the department, then the correct response is either: a) Sally's interface has already updated to reflect the fact that the department has been deleted, so she doesn't even have the option to delete anymore b)(where realtime updating of the interface isn't possible) - when Sally tries to modify the deleted record she is presented with a message stating that the action failed due to the department having been deleted by Bob. Sally can now either undo Bob's delete first (or ask Bob to do it), and then undo her own change. User confirmation dialogues are a UI smell, in the same way that a module of code stuffed with if statements and flags is a code smell. It's telling you that your design has a fundamental flaw that needs to be fixed in a non-trivial way. Just t hink about the basic question - should red be "delete" or "no". Either way, the question implicitly recognises that this situation is confusing, and that Sally has a good chance of making a mistake. Knowing that her problem has arisen because she clicked on the wrong button ("when it was clearly coloured red!") is not going to make Sally like your software. Make it so that she can fix her error, not so that she doesn't make the error in the first place.