[rolenthedeep]

Yeah, the OS itself was passable. It had the absolute bare minimum required to work, so not much could go wrong.

The ancient software also wasn't bad. After a few months learning the hotkeys and menu structure, the speed with which you can enter and process data was absolutely incredible. It had problems, but usually minor and patched in a reasonable time for corporate IT.

The real problem was their database management. I don't have any information, so I'm assuming here, but my impression is that they're using some positively ancient database software. Doing a backup of the local cache took multiple days, though it didn't lock the DB. Requests to HQ were incredibly slow, about 30 seconds to pull an account record. Larger queries like neighboring store inventory took a minute or two. Running a report on local inventory would regularly take tens of minutes, and it only had to read the local cache.

The database was a few tens of GB on disk. Granted, I don't know much about databases, but if running something like "SELECT * FROM inventory WHERE sales < 100 ORDER BY lastSaleDate" on a 30gb database takes 15 minutes, something is wrong.

There were a lot of problems we ran into on a daily basis, and almost all of them related to database functions. Particularly when a record failed to unlock, sometimes we'd have to reboot the local server, which caused all terminals in the store to reboot. That usually took a good 15 minutes.

Personally, I rather enjoyed not having Windows at work. For the most part, everything Just Works, and given the hardware, it ran ten times faster than windows would have.

My current job is a Windows development shop, and I don't have enough curses to describe the pure rage I feel every time windows does something stupid (which is approximately every three hours).

[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.