No, they are not qualified, and the project wouldn't be done internally. The USPS is a treasure trove of outsourced, poorly-implemented half-done years-late projects, such as Flats Sequencing System and eInduction. The whole entity looks like a gigantic money funnel to companies like Northrup and Accenture.
And it's these 400 customers who demand delivery tracking. USPS performance is inconsistent across facilities and they are always pulling tricks like "unload incoming bulk mail and let sit for 2 days before doing an inbound scan". Those 400 customers want to know why a percentage of their multi-million-dollar bulk mailing arrived in the mailbox after the sale was over. That's what drives the tracking initiatives.
USPS has the APIs but they are so obtuse and FIPS-standards-laden that the USPS points you to Indicia or Pitney Bowes if you ask about implementing the API.
At 42, I can tell you it gets worse. The idiocy of management is boundless, as is their energy in pushing their ideas and their inability to absorb any information.
Yes, I've had the misfortune to hear countless client complaints resulting from their failure to lower the TTL well in advance of a planned DNS change on a key host.
In summary - once the DNS information is changed in the database, the DNS server continues to serve out stale information for the next 10,000+ queries.
You may have better luck with a script designed specifically to convert mysql to pg. We use one as part of our ora to PG migration project (ora2pg). It's not perfect but it works pretty well. A quick search showed a couple of options for mysql, maybe something like http://sourceforge.net/projects/mysql2pg/ would give you better luck. pg_dump isn't much better at bringing in dumps than psql is. These dedicated conversion scripts usually take advantage of perl DBI connectivity to both DBs simultaneously, versus trying to export ddl and sql, and it seems to be a more successful approach.
Yeah guy, you schooled me. You can't write a script to make those seemingly-minor tweaks to the mysqldump output? FWIW psql can barely import PG's own dumps. I think in the realm of rdmbs you'll find that product A's software for outputting to product B's import format is _always_ at least slightly broken.
The problem is that database abstraction (at the level sufficient to throw a switch to change DB platforms) carries a performance price. If you've scaled your business to the point that you "need" SQL Server (as if it outperforms mysql), as the OP was suggesting, you have probably de-abstracted yourself to the point that swapping DBs will be a serious pain.
Slashdot Mirror
I have no idea what "AAA" means in video game context, either. I am not a gamer. I know plenty of geeks that don't game.
It's just for a "study", aka a way to funnel govt money into the private sector.
No, they are not qualified, and the project wouldn't be done internally. The USPS is a treasure trove of outsourced, poorly-implemented half-done years-late projects, such as Flats Sequencing System and eInduction. The whole entity looks like a gigantic money funnel to companies like Northrup and Accenture.
And it's these 400 customers who demand delivery tracking. USPS performance is inconsistent across facilities and they are always pulling tricks like "unload incoming bulk mail and let sit for 2 days before doing an inbound scan". Those 400 customers want to know why a percentage of their multi-million-dollar bulk mailing arrived in the mailbox after the sale was over. That's what drives the tracking initiatives.
You complained a year ago about a choice Netflix made five years ago? Wow, you've got the pulse of technology.
USPS has the APIs but they are so obtuse and FIPS-standards-laden that the USPS points you to Indicia or Pitney Bowes if you ask about implementing the API.
..."thousands of bugs" he says, on the heels of a fairly large remotely-exploitable openssl security hole. Go OSS!
You disagree that many, if not most, organizations are plump with multiple layers of ineffective management?
At 42, I can tell you it gets worse. The idiocy of management is boundless, as is their energy in pushing their ideas and their inability to absorb any information.
Yes, I've had the misfortune to hear countless client complaints resulting from their failure to lower the TTL well in advance of a planned DNS change on a key host.
In summary - once the DNS information is changed in the database, the DNS server continues to serve out stale information for the next 10,000+ queries.
Mod up!
We don't know that he wasn't granted lenience, the case never even went to trial.
Amen!
Yes, because Microsoft is barely breaking even.these days.
Are you paying attention? We're talking about usable output above 22k. A 3dB rolloff at 15k is going to be what at 22k?
But what's the upper frequency cutoff of the speaker?
http://goo.gl/d04pmI
You may have better luck with a script designed specifically to convert mysql to pg. We use one as part of our ora to PG migration project (ora2pg). It's not perfect but it works pretty well. A quick search showed a couple of options for mysql, maybe something like http://sourceforge.net/projects/mysql2pg/ would give you better luck. pg_dump isn't much better at bringing in dumps than psql is. These dedicated conversion scripts usually take advantage of perl DBI connectivity to both DBs simultaneously, versus trying to export ddl and sql, and it seems to be a more successful approach.
Yeah guy, you schooled me. You can't write a script to make those seemingly-minor tweaks to the mysqldump output? FWIW psql can barely import PG's own dumps. I think in the realm of rdmbs you'll find that product A's software for outputting to product B's import format is _always_ at least slightly broken.
The problem is that database abstraction (at the level sufficient to throw a switch to change DB platforms) carries a performance price. If you've scaled your business to the point that you "need" SQL Server (as if it outperforms mysql), as the OP was suggesting, you have probably de-abstracted yourself to the point that swapping DBs will be a serious pain.
"Issues with double quotes vs single quotes vs ticks" = someone writing code in 2013 that isn't using bound parameters.
Do you realize how difficult and time consuming it is to switch a large codebase from one RDMBS to another?
Wow...
PHP drove mysql's adoption, it had mysql db functions baked-in. PG was added later.