The requirements for the project ask for a consecutive integer (with a letter or letters appended at the end for the branch it belongs to). So that means no gaps. Assuming I have branch A, B and C the invoices would need to be: For branch A: 1A 2A 3A ... For branch B: 1B 2B 3B ... For branch C: 1C 2C 3C ... So I was looking for a way to have primary key that is an auto-increment integer for all branches and some sort of secondary key that is also an auto-increment integer but depending on the branch. Maybe it could be done with a computed field, but I'm not sure. Any ideas? And thanks for the helpl.
El viernes, 29 de noviembre de 2013 13:52:56 UTC-6, Niphlod escribió: > > does unique means with no gaps or just monotonic ? Should that data be an > integer ? there are tons of ways to have unique numberings just based on > the fact that any given branch can produce a limited amount of invoices in > a preset period of time. > If, e.g., your company usually issues 50k invoices a year (more than a > hundred a day, more than 4k a month) for any given "branch", assuming > branches are 30..... > > a good scheme is > 2 places for the current year --- 13 > 2 places for the "branch code" -- 01, 02, 03, etc > 5 places for the "monotonic" counter ---- 00001 to 50000 (heck, if they > start issuing invoices for every pen bought by employees, you can reach > 100k invoices a year) > > this basically compose a number that is > 130100001 to 130199999 for the "first branch" > 130200001 to 130299999 for the "second branch" > and so on. > given the previous assumptions, you'd likely end up at the end of the year > having > 130100001 to 130149999 > 130200001 to 130249999 > > In any case, those kind of integers are fully representable with a normal > "int" field, that in most dbs holds values (for positive integers) up until > 2^31 ... that is 2147483647. Don't worry. Even if your app still works in > 2113, you'd still reach > 1135099999 > for the latest invoice of the latest branch that is far beyond the > theoretical limit of ints. > If you want to spend 8 bytes for every invoice number instead of 4, you > can still go with bigint and you could generate zillions of invoices a year > for a zillion branches for a zillion years. > > Where's the issue ? > > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
