3 ms·

Back in the mid-90s, this was how many of the high-end web apps were built, using Oracle. Despite its limitations, and Oracle license fees (but back then you we

Back in the mid-90s, this was how many of the high-end web apps were built, using Oracle. Despite its limitations, and Oracle license fees (but back then you were paying for Sun servers anyway), it worked surprisingly well and was a reasonable model for many database-driven web applications. Some of these systems were used for mission-critical global operations handling enormous amounts of money and complex business. It had a lot of advantages versus other web app stacks at the time (commonly a mountain of Perl). Oracle was happy to sell database licenses but made zero effort to develop this way of using the database as a first-class capability. They were astonished that it even worked as well as it did, they did not expect people to take it that far. For some types of applications, something along these lines is likely still a very ergonomic way of writing web apps, if the tooling was polished for this use case.

pjmlp 6y ago
I can assure you that still is how many high-end web apps are built today. Just delivered one last month with plenty of T-SQL code in it.
- kemiller2002 6y ago
  Not surprising. Databases are built to be really efficient, and with enough hardware, they can forgive a lot. Mediocre developers can produce a lot of "working" code if they stand on the shoulders of giants. (Not saying you or your team was mediocre, I'm just saying that I've seen really bad code run a lot of business processes. At the end of the day, it worked and the company made money.)
  - pjmlp 6y ago
    Just like I keep seeing plenty of mediocre teams doing for loops over GB of downloaded data and pegging Webserver CPUs for stuff that should have stayed on the DB. Usually that is one of the things I end up fixing when asked for performance tips, other is getting rid of ORMs and learn SQL.
    - kemiller2002 6y ago
      Oh don't get me wrong, there is a time and a place for everything. There are many things that should be in the database, and there are a lot of people that avoid it because they don't want to learn SQL. You can have really good reasons and elegant code in SQL. I'm merely saying when someone immediately says, "that's dumb, you shouldn't do that," they aren't looking at the whole picture possibly and it was the choice that got the programming running which is important.
    - jacques_chester 6y ago
      I did a take-home exercise earlier this week. They provided access to a database and said << do thing >>. Implied was that I should << do thing >> with a program rather than a query. One of my solutions used Golang. It pulled data, looped a lot, then put results back. It took approximately 4 minutes. I included a second solution, using SQL. It selected into the results table with a little bit of CTE magic. It took approximately 600ms.
      - bartread 6y ago
        Interesting, and I've seen and implemented similar optimisations plenty of times. The right query in the right place at the right time can make all the difference. Did you hear back from them with a positive response?
        jacques_chester 6y ago
        Not yet, but it's a small firm. I trust the people involved and I don't mind giving them some time to go over it.
        bartread 6y ago
        Well, best of luck: I hope you get the job.
    - NicoJuicy 6y ago
      ORM's aren't that slow, they are quick to develop. When you see a bottleneck, you could use 2 systems ( eg. EF by default and Dapper when doing optimizations)
kemiller2002 6y ago
It should be noted too that the 90s was really a different world back then. Processing capabilities, and development tools were vastly different. There was just so much stuff that you had to manually build you don't have to now. (There are other complexities that we get to worry about now.) One thing I noticed back then is that putting stuff in the database just made things easier. In some instances, it really did act as like an amplifier for getting work done. Need to sort data? The database has things in place to do that and really efficiently too. I remember working with people, and if they had to make things like a linked list or a binary tree, they were lost (Yes, these were CS people too. We can argue about their education, but yes, they did graduate with a CS degree). There was nothing really like Stack Overflow to ask for help. You were really on your own for a large portion of it. Database code really took care of a lot of that for you. (Truthfully, the companies I worked for used MSSQL Server back then, so your results might have been different.)
- jandrewrogers 6y ago
  Another unusual usage for SQL databases (today!) is as a data type server. SQL databases have a very rich set of data types with rigorous specification and myriad operators, conversions, etc for all the types, more so than just about any other programming environment. If you need correct support for a complex data type operation in a development environment with weak or non-existent type support, you can use a SQL runtime to do that computation for you over a local client connection. I've used PostgreSQL this way a few times to great effect. The connection is over local IPC and never touches storage, so the operation throughput is quite high.
- throwaway201103 6y ago
  Yeah nobody in the 1990s with a real CS degree didn't know what a linked list or binary tree was. They just didn't want to bother coding it and testing it, when the database was there and being used anyway.

pjmlp 6y ago

I can assure you that still is how many high-end web apps are built today. Just delivered one last month with plenty of T-SQL code in it.

kemiller2002 6y ago
Not surprising. Databases are built to be really efficient, and with enough hardware, they can forgive a lot. Mediocre developers can produce a lot of "working" code if they stand on the shoulders of giants. (Not saying you or your team was mediocre, I'm just saying that I've seen really bad code run a lot of business processes. At the end of the day, it worked and the company made money.)
- pjmlp 6y ago
  Just like I keep seeing plenty of mediocre teams doing for loops over GB of downloaded data and pegging Webserver CPUs for stuff that should have stayed on the DB. Usually that is one of the things I end up fixing when asked for performance tips, other is getting rid of ORMs and learn SQL.
  - kemiller2002 6y ago
    Oh don't get me wrong, there is a time and a place for everything. There are many things that should be in the database, and there are a lot of people that avoid it because they don't want to learn SQL. You can have really good reasons and elegant code in SQL. I'm merely saying when someone immediately says, "that's dumb, you shouldn't do that," they aren't looking at the whole picture possibly and it was the choice that got the programming running which is important.
  - jacques_chester 6y ago
    I did a take-home exercise earlier this week. They provided access to a database and said << do thing >>. Implied was that I should << do thing >> with a program rather than a query. One of my solutions used Golang. It pulled data, looped a lot, then put results back. It took approximately 4 minutes. I included a second solution, using SQL. It selected into the results table with a little bit of CTE magic. It took approximately 600ms.
    - bartread 6y ago
      Interesting, and I've seen and implemented similar optimisations plenty of times. The right query in the right place at the right time can make all the difference. Did you hear back from them with a positive response?
      - jacques_chester 6y ago
        Not yet, but it's a small firm. I trust the people involved and I don't mind giving them some time to go over it.
        bartread 6y ago
        Well, best of luck: I hope you get the job.
  - NicoJuicy 6y ago
    ORM's aren't that slow, they are quick to develop. When you see a bottleneck, you could use 2 systems ( eg. EF by default and Dapper when doing optimizations)

kemiller2002 6y ago

It should be noted too that the 90s was really a different world back then. Processing capabilities, and development tools were vastly different. There was just so much stuff that you had to manually build you don't have to now. (There are other complexities that we get to worry about now.) One thing I noticed back then is that putting stuff in the database just made things easier. In some instances, it really did act as like an amplifier for getting work done. Need to sort data? The database has things in place to do that and really efficiently too. I remember working with people, and if they had to make things like a linked list or a binary tree, they were lost (Yes, these were CS people too. We can argue about their education, but yes, they did graduate with a CS degree). There was nothing really like Stack Overflow to ask for help. You were really on your own for a large portion of it. Database code really took care of a lot of that for you. (Truthfully, the companies I worked for used MSSQL Server back then, so your results might have been different.)

jandrewrogers 6y ago
Another unusual usage for SQL databases (today!) is as a data type server. SQL databases have a very rich set of data types with rigorous specification and myriad operators, conversions, etc for all the types, more so than just about any other programming environment. If you need correct support for a complex data type operation in a development environment with weak or non-existent type support, you can use a SQL runtime to do that computation for you over a local client connection. I've used PostgreSQL this way a few times to great effect. The connection is over local IPC and never touches storage, so the operation throughput is quite high.
throwaway201103 6y ago
Yeah nobody in the 1990s with a real CS degree didn't know what a linked list or binary tree was. They just didn't want to bother coding it and testing it, when the database was there and being used anyway.