Factor this.
-
Or the enterprise numbers table with a number type column and reference table for prime, not prime, the associated entities, wcf service methods and all the unit tests IsXXXXXPrime. :-D
Andy Brummer wrote:
Or the enterprise numbers table with a number type column and reference table for prime, not prime, the associated entities, wcf service methods and all the unit tests IsXXXXXPrime.
My Boy, you not only keep your job, but I'm giving you seniority!
I wanna be a eunuchs developer! Pass me a bread knife!
-
The system that I work on has a sql table that encodes a hierarchy with 2 columns. The first has prime numbers and the second has the value from the first column multiplied by all the keys of the parents for that row. To get all the children for a row you get all records where the current key divides the value for the second column. :|
-
Or the enterprise numbers table with a number type column and reference table for prime, not prime, the associated entities, wcf service methods and all the unit tests IsXXXXXPrime. :-D
-
The system that I work on has a sql table that encodes a hierarchy with 2 columns. The first has prime numbers and the second has the value from the first column multiplied by all the keys of the parents for that row. To get all the children for a row you get all records where the current key divides the value for the second column. :|
That's so unbelievably wrong. You must need to keep the number of entries in the table fairly small, considering what a complete hash of things would happen in the event of an overflow in the second column value.
Software Zen:
delete this;
Fold With Us![^] -
The system that I work on has a sql table that encodes a hierarchy with 2 columns. The first has prime numbers and the second has the value from the first column multiplied by all the keys of the parents for that row. To get all the children for a row you get all records where the current key divides the value for the second column. :|
erm, why? At least it makes my MS Access application, that contains a table with a single dateTime column containing the dates of the last day of the month seem somehow quite technically sound!
___________________________________________ .\\axxx (That's an 'M')
-
That's so unbelievably wrong. You must need to keep the number of entries in the table fairly small, considering what a complete hash of things would happen in the event of an overflow in the second column value.
Software Zen:
delete this;
Fold With Us![^]I know, not to mention a table scan with every lookup. The primes I saw were in the 900 range at least, so there would definitely be the potential for overflow. Good thing the hierarchy is only a few levels deep. The only other anti-pattern like that was doing bit fields for security lookups on some web site I'm not going to mention.
-
erm, why? At least it makes my MS Access application, that contains a table with a single dateTime column containing the dates of the last day of the month seem somehow quite technically sound!
___________________________________________ .\\axxx (That's an 'M')
It is definitely inventive, and it does work, so I can't fault anyone on that. However, I think it will be "refactored" sometime soon.
-
After working with Oracle that has been overcustomized for 10 months, I think this may be an improvement.
Soon...very soon...http://CraptasticNation.blogspot.com/[^]
Holy crap, that must be beastly.
-
Holy crap, that must be beastly.
-
The system that I work on has a sql table that encodes a hierarchy with 2 columns. The first has prime numbers and the second has the value from the first column multiplied by all the keys of the parents for that row. To get all the children for a row you get all records where the current key divides the value for the second column. :|
A geeky remark: This prime number multiplication game is the essence of the "Godel numbering scheme" invented in the 1930's by the mathematician Kurt Godel and used by him to prove that all formal systems are either inconsistent or incomplete - very cool if you are a mathematician. The "problem" with this approach is that it quickly produces huge (vast) numbers if your tree is big and deep. But good idea! :)
Why make life more difficult than it is?