[anyfoo]

Ugly. This makes me seriously wonder whether they just did not put an index in, and unfathomably many hours have been wasted on useless full table scans for something that would have been fixed with a handful of CREATE INDEX statements? Though that's a lot of conjecture, and the real answer is probably more complex. But your examples do make me wonder...

[rolenthedeep]

I remember running some very large reports over multiple years of inventory movement. Disk access on the server was totally saturated for a good 20-30 minutes.

Thinking about it now, it had to have read out the entire database multiple times.

Oh yeah, these reports weren't processed on the server, either. The network link on the terminal I used would be pegged at the max rate the server could read from the disk. I never really figured out what that's about.

I guess it's trying to stream large chunks of the DB to the terminal and running the query locally? No clue.

[orangepurple]

Some genius probably thought processing queries locally would be faster than on the database server. Fail.

[SoftTalker]

Likely wasn't a RDBMS at all, but flat files with maybe one key index (or perhaps none).

[rolenthedeep]

I really doubt that a schema like that would survive at the kind of scale SW operates at. I'm about 80% sure I saw mention of database operations in the startup/shutdown logs, but I could be misremembering.

My guess is that they bought whatever database software was popular in the early 90s and never changed.

I do know they've been slowly changing the schema over the years, increasing the number of digits in the account number, adding email fields, that kind of thing. But I doubt there's been any major upgrades.

[SoftTalker]

Well early 1990s database sofware wasn't awful. Talking about stuff like Sybase 4.x, roughly equivalent to early MS SQL server, also Oracle, Informix, DB/2, etc. Indexes, query planning (perhaps with hints), cursors, concurrency, were all adequately solved problems by then.