referring now to fig1 , a data repository system is indicated generally at 50 . in a present embodiment , system 50 is presented in the context of a wireless telecommunications system , but it is to be understood that system 50 can be varied to other contexts . system 50 comprises a plurality of service control points (“ scps ”) 54 - 1 , 54 - 2 ( collectively , scps 54 , and generically , scp 54 .). scps 54 are connected , via a network n - 1 , to a plurality of applications 58 - 1 , 58 - 2 ( collectively , applications 58 , and generically , application 58 ). applications 58 are , in turn , are serviced , via a second network n - 2 , by one or more primary databases 62 p which in turn can be backed - up by one or more secondary databases 62 s service data points . ( collectively , databases 62 and generically , databases 62 ). however , those skilled in the art will recognize that secondary databases 62 s can be omitted altogether . those skilled in the art will also now recognize that applications 58 and databases 62 can be collectively referred to as service data points ( sdps ). while the present embodiment , includes specific reference to network n - 1 and scps 54 , it will become apparent that network n - 1 and scps 54 can be omitted altogether , or scps can simply be any type of client machine that is accessing applications 58 . networks n - 1 and n - 2 are comprised of any network infrastructure components that are used to implement desired physically interconnections , and can , in fact be implemented on a single network . in the present embodiment , network n - 1 is implemented via ss7 network infrastructure , whereas network n - 2 is implemented via a local area network or a wide area network based on internet protocols . applications 58 can be any type of application that is currently known ( or is developed in the future ) that would serve data stored in databases 62 to scps 54 . a well known example of an application 58 is an application to route 1 - 800 - numbers to a traditional area code and phone number . other examples for applications 58 include customer resource management , cross - service bundling , location services and rating , virtual private networking , prepaid billing , missed call return , loyalty reward and promotion programs , fraud management , policy management , call screening and redirection , and subscriber profile management . databases 62 include the infrastructure to store , retrieve and manage data , including hardware to store the data and a database application layer , such as the structured query language (“ sql ”) or the like , to interface between each database 62 and each application 58 . referring now to fig2 a method for adding a database partition is represented in a flowchart indicated generally at 100 . method 100 can be performed on a variety of different systems , but in order to assist in explanation of system 50 and method 100 , it will be assumed that method 100 is performed using system 50 . in the present embodiment , database 62 p - 1 represents a single partition and that database 62 s - 1 represents a single partition . thus , to give a concrete example of the performance of method 100 , it will be assumed that database partition 62 p - 1 is full and that a second database partition 62 p - 2 is being added to database partition 62 p - 1 . method 100 can be implemented on any suitable computing environment ( e . g . a server ) with physical connections to each database partition 62 p in order to examine the existing partitions 62 p and determine how to move data on the existing partition ( s ) to the new partition . fig3 shows a representation of method 100 , drawn as an oval , operating on database partition 62 p - 1 so as to add database partition 62 p - 2 . ( though not shown , method 100 would likewise apply to the addition of a second database partition to database partition 62 s - 1 ). beginning at step 105 in fig2 , a determination is made as to the existing number of partitions . in the present example , it is determined that only one database partition 62 p - 1 currently exists . next , at step 110 , each existing partition is examined to determine which portion of each existing partition is to be transitioned to the new partition according to a minimally progressive hashing operation . the minimally progressive hashing operation is represented as an oval indicated at “ h ” in fig3 . in the present example , database partition 62 p - 1 would be examined and , assuming database partition 62 p - 1 was full , then hashing operation h would determine that half of the data thereon would be identified as a candidate for moving to new partition 62 p - 2 . hashing operation h would likewise identify which exact portions would be candidates for moving . next , at step 115 , the new partition would be added . in the present example database partition 62 p - 2 would become physically and operationally attached to and integrated with partition 62 p - 1 , such that each application 58 would perceive both partitions 62 p - 1 and 62 p - 2 to be a single database 62 p , such that each application 58 would continue to interact with partitions 62 p in the same manner as one partition 62 p . next , at step 115 , the new partition would be added . in the present example database partition 62 p - 2 would become physically attached to partition 62 p - 1 . next , at step 120 , portions of the existing database will be ported from the existing partition ( s ) to the new partition in accordance with the determinations made by hashing operation h at step 110 . at the conclusion of performance of step 120 , application 58 would perceive both partitions 62 p - 1 and 62 p - 2 to be a single database 62 p , such that each application 58 would continue to interact with partitions 62 p in the same manner as one partition 62 p . it is contemplated that during the performance of steps 115 and 120 , each application 58 will be able to access database 62 p in such a manner that , where an application 58 expects to find data on the second database partition 62 p - 2 as it would expect to find such data at the conclusion of the performance of step 120 , then that application 58 will initially look for that data on the second database partition 62 p - 2 , and , where that data is not found , then that application 58 will look for that data on the first database partition 62 p - 1 . an exemplary mechanism for accomplishing this is as follows : application 58 first attempts to find the data as though the migration to database 62 p - 2 had already been completed . if the data is not found by application 58 then application 58 would try to find the data again , but instead using the same method that application 58 used before database 62 p - 2 were added . a more sophisticated mechanism can be made aware of the progress of the data migration to database 62 p - 2 so that application 58 would know whether a particular piece of data had been migrated , or not . it will now be understood that method 100 can be used to add any number of partitions ( not shown in the figures ) to database partitions 62 p - 1 and 62 p - 2 , or to database 62 b . it should also be understood that hashing operation h can be implemented in a variety of ways . hashing operation h can be selected from a class of partitioning algorithms that share the unusual property that they substantially maintain a maximum , or substantially maximum , consistency between consecutive partition sizes . an example of one hashing operation h is provided in appendix i in the form of pseudo - code and referred to as hashing operation h - 1 . table i shows the progression of movement of data as method 100 is performed eight times , each time adding a new partition , using hashing operation h - 1 , so that at the conclusion database 62 p has a total of nine partitions referred to herein as 62 p - 1 , 62 p - 2 , . . . 62 p - 9 . in table i , the term “ key ” refers to the index or other pointer that identifies each portion of the database partition . thus , each partition in the example of table i has nineteen portions . it will be understood , however , that in other embodiments each partition can be divided into other portion sizes . the partition number beside each key indicates the location of the portion of data associated with that corresponding key . each “*” indicates that the portion corresponding to the * was moved during the previous performance of method 100 by hashing operation h - 1 . another example of a hashing operation h is provided in appendix 2 and referred to as hashing operation h - 2 . fig4 shows the progression of movement of data as method 100 is performed using hashing operation h - 2 , so that at the conclusion database 62 p has a total of eighteen partitions . each row in fig4 represents a key . each column represents the addition of a new partition . squares in a given row indicate that the data represented by this row need to be transitioned to a new partition as part of the migration caused by adding the new node represented by the corresponding column . the first column is solid because all data needed to be written into the first partition . moving across a row shows at which partition size increases a particular piece of data needed to be moved to the new partition . reading down a row shows which keys were copied into the new partition when the new partition was created . fig5 a and 5b are another representation of fig4 , except that fig5 a and 5b also show to which partition each key is allocated at each point in time . varieties of permutations , combinations , variations and / or subsets of the embodiments discussed herein are contemplated and will now occur to those skilled in the art . for example , system 50 can be varied for environments other than telecommunications , in which case databases 62 that serve applications 58 , can in turn service any type of client machine , and not just scps 54 . the second ‘ part ’ function above is limited by the growth of the ‘ factorial ’ function . as such , it can only be used for partition sizes a more complicated version is listed below which instead relies of the lcm ( lowest common multiple ) instead of the factorial . as a result hashing operation h - 2 is suitable for partition sizes of up to 42 .