41–50 of 73 posts
Earlier quoted context omitted.
Because some databases have a significant usage among web developers and web developers have a significant expertise in javascript.
Which sadly doesn't mean that they have a lot of experience in the algorithms involved when handling datasets.
Earlier quoted context omitted.
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.
i wonder if JS will empower any embedded hw projects soon. writing the next mars rover in js anyone?
Earlier quoted context omitted.
Which sadly doesn't mean that they have a lot of experience in the algorithms involved when handling datasets.
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.
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.
Earlier quoted context omitted.
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 t…
Exactly what bad things happen when you put logic in the database? At my current employer, most business logic is in stored procedures.
Earlier quoted context omitted.
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.
You know what's faster than JS? C. C, the language many VMs are built in and tasked with running these kinds of things.
Javascript strikes a nice balance between performance and high level usability.
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.
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 t…
Earlier quoted context omitted.
Which sadly doesn't mean that they have a lot of experience in the algorithms involved when handling datasets.
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.
Earlier quoted context omitted.
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 t…
Honest question. Where should you stick your db related logic if you don't want to replicate it in every app that touches the database. Do you write some sort of middleware that sits between the apps and the database and never let any apps talk directly to the database?
1. Sits in front of your data store and exposes your application's API via HTTP for example. Typical SOA/public API type architecture.
2. Sits inside your web application as a component which you talk to via your internal API. In a Ruby/Python/PHP/Java/C# setting, you would typically have a class with methods on it which correspond to API calls.
3. Ships with your application (if a desktop one for example) and serves an internal API. As above but the component ships with the desktop application.
We do 1 and 2 in our product using the same shared components (domain models).
In actual fact, it's completely hiding behind NHibernate so we don't actually ever consider the database as part of the problem that needs solving. It's purely where we put our stuff when we don't want it in memory.