5 Replies Latest reply: Jun 15, 2010 2:30 AM by YoungWinston RSS

    collection design question

    843793
      I need to come up with a design to hold unique records. Each record needs to be unique, except for a placeholder. Three types of sorting also need to be supported.

      A phone book, might be a good example. Each phone number needs to be unique, except I need to allow that there can be a placeholder if the customer's phone number is not know. So,

      802-333-1234 Doe, John, A Town
      802-333-4200 Doe, Jane, B Town
      802-412-3411 Person, Mary, C Town
      802-555-1212 Smith, John, B Town
      802-555-1212 Richards, Art, D Town
      802-333-1234 Hamels, Cole, E Town

      So, in this example 802-333-1234 should be identified as a duplicate.
      802-555-1212, however is a placeholder until I learn what John Smith and Art Richards real phone numbers are, so should not be marked as duplicates.
      I also need to be able to return an ordered list by phone number, by last name and by town with the unique constraints applied. I can think of ways to do it, but what are good object oriented ways using as much core api as possible?
        • 1. Re: collection design question
          843793
          I would create a simple POJO with the required fields (name, town, phone). In this POJO I would override equals method - to return false if a placeholder for phone is used (You can declare private static for placeholder). This move will enable You to use simple set as a collection (no duplicates excepting placeholder). The POJO class would also implement comparable and use an enum (e.g. SORT_BY_TOWN) with sort field defined. Using this comparable and the enum You will able to point the sorting key and sort the collection using Collections.sort(). Before the sorting You just need to create a list from a set or use a TreeSet which is ordered out of the box.
          • 2. Re: collection design question
            DrClap
            Usually the placeholder you would use for data which doesn't exist yet is simply "null". Why not just use that instead of reinventing it? And when you're checking for duplicate phone numbers, filter out any records where the phone number is null before you start the check.
            • 3. Re: collection design question
              843793
              DrClap wrote:Usually the placeholder you would use for data which doesn't exist yet is simply "null".
              Usually yes, but maybe in this case the persons are accessible under the palceholder number until the real number is known - so it might be useful.
              • 4. Re: collection design question
                843793
                It is correct that I need to display '999999999', so that overriding equals(Object o) so as to handle that case seems appropriate. I may also try implementing a getter that returns '999999999' whenever a null is returned.

                Thank you both for the responses.
                • 5. Re: collection design question
                  YoungWinston
                  mbackus wrote:
                  It is correct that I need to display '999999999', so that overriding equals(Object o) so as to handle that case seems appropriate. I may also try implementing a getter that returns '999999999' whenever a null is returned.
                  An alternative is that a precondition for placing someone in a phonebook is that they must have a phone number.
                  I believe this the way it's done by most phone companies: The first thing that happens is that you're given a provisional one from the set of unused numbers for your district. Almost always, this ends up being the number you actually get, so all you need to do is flag the number as "provisional" or "final".

                  It's probably worth pointing out that people are one of the hardest things to "key" in data management terms, because there's almost nothing about the way we identify someone that is unique; and even combinations of them (eg, name + birthdate) are often insufficient. That's why so many systems use proprietary sequence numbers such as "Customer ID"s.

                  Winston