7 ms·

Why would I choose to use JS in a DB? Why, oh why? This language has more quirks then a 2012 US Republican Presidential candidate.

by kelvin0 13y ago

bayesianhorse 13y ago
Because some databases have a significant usage among web developers and web developers have a significant expertise in javascript.
- Argorak 13y ago
  Which sadly doesn't mean that they have a lot of experience in the algorithms involved when handling datasets.
  - weego 13y ago
    Since when does every use of a database involve handling datasets in a way that needs experience and "algorithms". A key value store can be used as... a key value store if need be. It doesn't need to be crazy science.
    - Argorak 13y ago
      Once you start scripting your K/V store, its not a simple K/V store anymore. I am not against databases with scripting capabilities and I do not think javascript/front end developers are per se naive, but I've far to often seen the naive assumption that just because its javascript, everyone can handle it.
    - jmcdonald-ut 13y ago
      This isn't true. Once you have tens of thousands of records, a poorly written algorithm or data structure is going to lead to O(n^2) behavior. That hurts. Even small sites can hit this amount of database records with ease.
- bsg75 13y ago
  So if database developers have significant experience in SQL, they should author websites using templating engines that generate HTML using SQL? (This is only partially sarcastic as there were a few RDBMS + HTML template products that mercifully died).
kryten 13y ago
That's the first thing I thought. Having spent literally the last 10 years removing stored procedures and extensions from software products to eek out a little more from the black box that is a database engine and remove all the rats nest of logic, why would I want to go and do the same all over again? Of all the things I've learned in the last 20 years or so, you shouldn't stick any logic or programmability inside the database engine. It's hell down the line. And don't get me started on where the programmability abstraction gets fudged in with the data resulting in executable data and all sorts of security hell.
- kijin 13y ago
  In a key-value store like Redis, it's actually quite useful to be able to generate an atomic query that says something like "If List A contains B, return C. Otherwise check whether List D contains E, and if so, return all the keys and values of Dictionary F, but otherwise return zero." But of course, Redis already has Lua scripting which is a nearly perfect fit for its use case. JavaScript looks terribly cluttered by comparison. Some sort of V8 integration might make sense if the goal is to make Redis even easier to use with node.js, but I don't see anything in the documentation to suggest that this is what's happening.
  - kryten 13y ago
    Couldn't this be handled with some conditional primitives like in ARM assembly adequately? Actually that's not a bad idea ... writes it down...
- andrewflnr 13y ago
  Exactly what bad things happen when you put logic in the database? At my current employer, most business logic is in stored procedures.
  - kryten 13y ago
    Lots. Here you go: 1. CPU time goes up. When you need to scale up, your brick wall is a lot closer. 2. When you do need to scale up, moving it out of the database engine is very expensive and time consuming. 3. The languages are archaic, obtuse and inadequate for representing business logic and don't cover ALL concerns. How do you call a web service and do an update in a transaction for example? How do you send an email? 4. It's incredibly difficult to test as the entire thing is stateful. 5. Error handling and reporting is terrible. 6. You lose database portability. This is a big issue these days, particularly when you get whacked with major licensing model changes. 7. Versioning and deployment with the application is utterly painful. Etc etc...
h0x91b 13y ago
1) JS is easy, almost everyone can work with it. 2) V8 is faster than LUA 5-10 times........ 3) MVC - Model and crons, i think should be in DB.
- diminish 13y ago
  i wonder if JS will empower any embedded hw projects soon. writing the next mars rover in js anyone?
  - kryten 13y ago
    No, because it's entirely non deterministic and mostly an evolved shit-crock rather than an engineering tool.
- __alexs 13y ago
  You know there is a redis fork that uses LuaJIT right? https://github.com/neomantra/redis https://github.com/neomantra/redis
- tete 13y ago
  2) Faster than LUA-JIT? Since when?
- wheaties 13y ago
  You know what's faster than JS? C. C, the language many VMs are built in and tasked with running these kinds of things.
  - evilduck 13y ago
    And ASM is faster than C. Javascript strikes a nice balance between performance and high level usability.
- Shorel 13y ago
  V8 faster than Lua-JIT sounds like a really bold claim. AFAIK it is the other way around, with a factor of 3x.

Why would I choose to use JS in a DB? Why, oh why? This language has more quirks then a 2012 US Republican Presidential candidate.

by kelvin0 13y ago

Why would I choose to use JS in a DB? Why, oh why? This language has more quirks then a 2012 US Republican Presidential candidate.

bayesianhorse 13y ago

Because some databases have a significant usage among web developers and web developers have a significant expertise in javascript.

Argorak 13y ago
Which sadly doesn't mean that they have a lot of experience in the algorithms involved when handling datasets.
- weego 13y ago
  Since when does every use of a database involve handling datasets in a way that needs experience and "algorithms". A key value store can be used as... a key value store if need be. It doesn't need to be crazy science.
  - Argorak 13y ago
    Once you start scripting your K/V store, its not a simple K/V store anymore. I am not against databases with scripting capabilities and I do not think javascript/front end developers are per se naive, but I've far to often seen the naive assumption that just because its javascript, everyone can handle it.
  - jmcdonald-ut 13y ago
    This isn't true. Once you have tens of thousands of records, a poorly written algorithm or data structure is going to lead to O(n^2) behavior. That hurts. Even small sites can hit this amount of database records with ease.
bsg75 13y ago
So if database developers have significant experience in SQL, they should author websites using templating engines that generate HTML using SQL? (This is only partially sarcastic as there were a few RDBMS + HTML template products that mercifully died).

kryten 13y ago

That's the first thing I thought. Having spent literally the last 10 years removing stored procedures and extensions from software products to eek out a little more from the black box that is a database engine and remove all the rats nest of logic, why would I want to go and do the same all over again? Of all the things I've learned in the last 20 years or so, you shouldn't stick any logic or programmability inside the database engine. It's hell down the line. And don't get me started on where the programmability abstraction gets fudged in with the data resulting in executable data and all sorts of security hell.

kijin 13y ago
In a key-value store like Redis, it's actually quite useful to be able to generate an atomic query that says something like "If List A contains B, return C. Otherwise check whether List D contains E, and if so, return all the keys and values of Dictionary F, but otherwise return zero." But of course, Redis already has Lua scripting which is a nearly perfect fit for its use case. JavaScript looks terribly cluttered by comparison. Some sort of V8 integration might make sense if the goal is to make Redis even easier to use with node.js, but I don't see anything in the documentation to suggest that this is what's happening.
- kryten 13y ago
  Couldn't this be handled with some conditional primitives like in ARM assembly adequately? Actually that's not a bad idea ... writes it down...
andrewflnr 13y ago
Exactly what bad things happen when you put logic in the database? At my current employer, most business logic is in stored procedures.
- kryten 13y ago
  Lots. Here you go: 1. CPU time goes up. When you need to scale up, your brick wall is a lot closer. 2. When you do need to scale up, moving it out of the database engine is very expensive and time consuming. 3. The languages are archaic, obtuse and inadequate for representing business logic and don't cover ALL concerns. How do you call a web service and do an update in a transaction for example? How do you send an email? 4. It's incredibly difficult to test as the entire thing is stateful. 5. Error handling and reporting is terrible. 6. You lose database portability. This is a big issue these days, particularly when you get whacked with major licensing model changes. 7. Versioning and deployment with the application is utterly painful. Etc etc...

h0x91b 13y ago

1) JS is easy, almost everyone can work with it. 2) V8 is faster than LUA 5-10 times........ 3) MVC - Model and crons, i think should be in DB.

diminish 13y ago
i wonder if JS will empower any embedded hw projects soon. writing the next mars rover in js anyone?
- kryten 13y ago
  No, because it's entirely non deterministic and mostly an evolved shit-crock rather than an engineering tool.
__alexs 13y ago
You know there is a redis fork that uses LuaJIT right? https://github.com/neomantra/redis https://github.com/neomantra/redis
tete 13y ago
2) Faster than LUA-JIT? Since when?
wheaties 13y ago
You know what's faster than JS? C. C, the language many VMs are built in and tasked with running these kinds of things.
- evilduck 13y ago
  And ASM is faster than C. Javascript strikes a nice balance between performance and high level usability.
Shorel 13y ago
V8 faster than Lua-JIT sounds like a really bold claim. AFAIK it is the other way around, with a factor of 3x.