Earlier quoted context omitted.
Yup. I've seen 55+ year old programmers write what was essentially a message queue persisted in a database table, processed by a cron job. We frequently had problems with duplicate processing of messages, due to multiple cron jobs running at once. I've personally argued against a key-value store schema in SQL Server and was in favor of a flat-table design. In our case, there were records of different 'types', and eac…
>All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing. I'm and old programmer and I've been arguing against business logic in SPs since SQL Server 6.5 and have been losing ever since. That's not an old/young argument. It's because vendors (in this case MS) recommend putting…
Oh I wasn't saying it was -- just providing examples for when the hand-waving/dismissive attitude by senior developers isn't really backed by anything. I'm pretty skeptical of 'because I said so' answers nowadays (by both young and old devs).
>then have the key/value schema for anything oddball
Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)