Thank you David!
Sorry for late jump into this thread.
- About Berkeley DB.
Do you know that it is free only for open source projects? Otherwise it is cost money, and price is not more not less than 100K$. Also it belongs to Oracle now as I remember.
Oliver did made a very good point that Valentina DB can be perfectly used as NO_SQL db. Actually it was borned as such, SQL was added few years later.
Lets discuss this?
Can somebody name at least 1-2-3 points which YOU expect to get from no-sql db? Scott? Robert?
Meanwhile I will mention few points which they usually name.
1) no SQL.
this is cool? Who think so? Sometimes yes. Sometimes no. You need know when and what is better.
Valentina is THE ONLY (?) database, which gives you the best of both worlds: SQL and API access to db.
Both works as with LOCAL files so with VSERVER. Do you know any other such DB? I think no.
Valentina for Xojo plugin gives you about 1000 (!) methods in 40-50 classes. All with nice OO.
You can do anything using only this methods
2) KEY-VALUE – yess very modern words.
should I mention that on goole you can find fresh articles that this can be required for huge storages, that have google itself, but this have no sense for normal DB tasks.
But … if you want Key-Value, Valentina is columnar. Valentina gives you API. Just make table with 2 fields { Key, Value } and be happy.
3) SPEED
Anybody did have troubles with speed of Valentina ?
Just in case will mention here one of last benches. 10 millions search by ULONG KEY in table with 10 millions records, having 1.2GB index on this field … 22-23 seconds on Mac Book/i7
4) JSON
We can read that Mongo/Coatch do good job with JSON …
I never did read what exactly …
But how many from you work with JSON documents?
Okay Andreas above says he do … but he also says he SELF do parse that document … then I wonder what trouble save it into Postgre or Valentina DB?
Other points guys?
Ruslan, I didn’t realize that. Time to read the fine print… 
I know one team in my city, which have worked with Mongo last 2 years. The only advantage they was able to name finally – scalability. Okay I agree. Sounds to be true. Explain is: it is much much simpler than Relational DBs, so they have simpler task to resolve scalability. They have used Amazon data servers, and they say me, they can easy scale number of servers … For example with mySQL this will be much much harder.
I don’t know. Did not try This is what they say 
But they develop online ORM project, so they can expect, if successful, big number of visitors.
On the other hand … how many bad words and that Mongo I have hear from them… Again exists articles.
As I understand main trouble – no strict schema, as in relational dbs, so you easy start to add something, but then your db fast transforms into big heap of garbage, which harder and harder to manage.
I’ve worked with a BTree database for years. It’s what I’ve been looking for.
[quote=34892:@Ruslan Zasukhin]Oliver did made a very good point that Valentina DB can be perfectly used as NO_SQL db. Actually it was borned as such, SQL was added few years later.
Lets discuss this?
Can somebody name at least 1-2-3 points which YOU expect to get from no-sql db? Scott? Robert?
Meanwhile I will mention few points which they usually name.
1) no SQL.
this is cool? Who think so? Sometimes yes. Sometimes no. You need know when and what is better.
Valentina is THE ONLY (?) database, which gives you the best of both worlds: SQL and API access to db.
Both works as with LOCAL files so with VSERVER. Do you know any other such DB? I think no.
Valentina for Xojo plugin gives you about 1000 (!) methods in 40-50 classes. All with nice OO.
You can do anything using only this methods
2) KEY-VALUE – yess very modern words.
should I mention that on goole you can find fresh articles that this can be required for huge storages, that have google itself, but this have no sense for normal DB tasks.
But … if you want Key-Value, Valentina is columnar. Valentina gives you API. Just make table with 2 fields { Key, Value } and be happy.
3) SPEED
Anybody did have troubles with speed of Valentina ?
Just in case will mention here one of last benches. 10 millions search by ULONG KEY in table with 10 millions records, having 1.2GB index on this field … 22-23 seconds on Mac Book/i7
4) JSON
We can read that Mongo/Coatch do good job with JSON …
I never did read what exactly …
But how many from you work with JSON documents?
Okay Andreas above says he do … but he also says he SELF do parse that document … then I wonder what trouble save it into Postgre or Valentina DB?
Other points guys?[/quote]
ok… why am I looking at MongoDB? several reasons.
the JSON doc that you store, you can index and/or query any part of that doc or sub doc ( or sub sub doc etc).
the “tables” arent fixed so I can store any docs/schemes I want. And not all docs have to look alike in the same “table”. for instance if I was doing an address/phonebook app. some people will have work addresses, some wont. some will have mobile #s, some wont. etc. With MongoDB, for the items that dont exist on a given record, the fields just dont exist. But when you query on the table, you dont get errors or worry about what is in that column that means it doesnt exist or anything. Also there is no scheme changes. Just make a change to your docs and you are golden.
it is **** fast.
it has built in sharding so I can shard the data over many hosts/instances or as little as 1 (pre-sharding for prep for growth).
it has built in replication ( shotgun, circular/chain, mesh, etc) methods from 3-12 nodes in the replication.
you can have sharding/replication running on the same table at the same time without performance hit.
it isnt a Key->Value store. you can make it one but it isnt one. if you want Key->Value, then there are other NoSQL (Or even Valetina DB) that would/could do better.
and that is just the few I can spout out right now. there are more.
sb
Great info Scott!
This sounds like sparse arrays, which I like.
[quote=34904:@Robert Kamarowski]I’ve worked with a BTree database for years. It’s what I’ve been looking for.
[/quote]
Good. I still remember old good dbVista III, with its Navigational model
Do you know that Valentina is hybrid in MANY directions. If talk about Database Models, then Valentina supports:
- Hierarchic Model (thanks to ObjectPtr field-link)
- Navigational model (thanks to ObjectPtr filed-link)
- Relational Model (Tables, Fields, Indexes, FK-link, Triggers, SPs, … )
- Object-Relational Model (adds BinaryLink, Properties on Tables, Fields, Indexes, Links.) And at one point we will add database Inheritance implemented in the “right way”.
dbVista did have problems, such as no way to change existed schema … Valentina do not have such problems. You can change anything in schema at runtime.
dbVista did have really navigational model, from record to record. In Valentina API you will find also work with Sets of records, similar to SQL. So we prefer say that Valentina supports “Extended Navigational Model”.
Is Valentina serverless (embedded)?
YES.
again Valentina is HYBRID in many directions. Including this one:
- Local only engine. VKERNEL.dll
- VCLient.DLL
they use same Interfaces, so for developer looks the sam, expect Database constructor.
So you can develop app, which works only with LOCAL db files, like SQLite.
you can develop app, which is client to remote VSERVER(s).
You can developer app, which works with few local dbs and few remote connections. – Valentina Studio example of such app.
P.S. I will read about Mongo from Scott later, busy now on 5.5b20 build.
[quote=34929:@scott boss]the JSON doc that you store, you can index and/or query any part of that doc or sub doc ( or sub sub doc etc).
[/quote]
Lets start with this …
Do you remember wave of XML-based-databases in about 2000 year +/- few year ?
They did big claims … WE WILL KILL this old stupid relational dbs!!
Do you remember this?
Where now that XML-killers?
And I can remember yet wave before that of OO-dbs. With same claim: We will kill all that Relational DBs.
But what did “stupid relational dbs”?
a) they have added FEW features and becomes Object-Relational DBs. Right?
b) they have added support of XML, who more, who less. in Valentina for example, we have made SELECT … FOR XML. We have copied this from MS SQL actually. MS SQL yet have more features: they have XML column and XML indexes. We was lazy for now to implement same … nobody asked in fact.
TODAY we starting work, by request from Xojo developer, on SELECT … FOR JSON
I think in 2-3 days we will finish it.
Store “JSON Document” … can go in TEXT field.
Index it? Okay, I think we can add that also
Any other [object]-relational DB also can do this step… right?
And back side of this is exactly REASON of HELL, look around on cry after this “freedom”.
Guys, google is your fiend. Simple search “problems with mongo db”, first answers. Why people have drop to use mongodb.
http://blog.scrapinghub.com/2013/05/13/mongo-bad-for-scraped-data/
Scott, is Pego ***** fast car?
- but what about speed of airplane?
- but what if compare to space shuttle?
Note, why Valentina’s Logo is space shuttle?
again, for me it is enough to point to same article: http://blog.scrapinghub.com/2013/05/13/mongo-bad-for-scraped-data/
copy paste from article:
[quote=34929:@scott boss]it has built in replication ( shotgun, circular/chain, mesh, etc) methods from 3-12 nodes in the replication.
you can have sharding/replication running on the same table at the same time without performance hit.
[/quote]
Agree, this is the only strong reason to which I agree.
But
How many from us develop huge, systems?
You really need tomorrow replications in your application?
You develop some HUGE ONLINE system with hundreds computers?
If yes, then yes you need think very careful in your choices
But I will argue: and having such huge system you going keep data in TEXT format of JSON ??
Just because this is comfortable for developer?
What about parse it to something more effective than text?
I don’t mind valid points, but please don’t make this into an advertisement forum for Valentina, and yes I have a Valentina license so i’m not against Valentina. It’s just that if people want to use MongoDB or something like it, it’s ok to point out that there are alternatives and one of them is Valentina, but this looks like it is turning more into a don’t use anything but Valentina because it is all bad. That is simply not true. There is a use case for all of them, or they would have been out of the market by now.
Just my 2c
hi Dirk,
nobody says all is bad nobody says Valentina is best of all
MS SQL have much strong support of XML format that Valentina DB have now. This is fact.
We just take discussion. Nothing bad if people will try explain why he think that such JSON-wow-based dbs can be better of old good dbs for HIS real life project… Not for Google Inc, Not for SomeElse Inc. But for his own real life project.
Also note, I mainly say Text-Document-based DBs vs Relational DBs…
My main point is: Any such Document-db will NOT will normal relational strong DB.
Especially as only RDBMS will add support of index on that text document.
Many RDBMS support even C/C++ plugins, so even third party can extend them …
THAT dbs do many noize about How Bad are relational dbs. Right?
Why we - relational DB vendors cannot say the same about them?
So far I have asked: WHAT TASK you cannot resolve in RDBMS?
Answers was list of features …
speed? – each RDBMS says it is fast
Scalability? – Oracle take first place all these year by benches on huge load.
So far I have not hear any strong reason, why ME, should choose Mongo for development of DB for University for example?
They seriously claim we need to stop develop schemas in DB ??
Teach me please
Let me explain one more point of view.
- when yet in 90s I have read something as:
Object-Relational DBs by OMG standard, can be developed only in OO language as C++ and Java.
I say Hmm… Why on earth Database MODEL, stored on disk, should relate to programming language, which access data???
In fact, no problems to have object-oriented data inside of disk file, and still use procedural language to work with that data.
- JSON format … have come from WEB world. Used often in JS language. Some like it more of XML. Okay.
But why on earth format comfortable to some programming language should dictate DB Model ?
This is nonsense IN MY OPINION.
Time have show that I was right with OO DBMS, then with XML DBs, when all around with big eyes have told me:
wow you have read that? How cool they are… wooow
It is soo easy to understand that something wrong here. I think JSON-based DBs will follow to XML-based DBs …
Yes, they have show need to support JSON.
RDBMS vendors will add this format and this stop game. Right?
All same as was with XML.
All talks about “Not Structured Records” - how this is cool. There is nothing new here. Year in 1993-1995, when was boom of OO db engines, they all did claim how cool this is, how this will kill relational model. And? NOTHING. This ideas did not works as good as wanted.
90% developers still use old good relational model with some extensions.
We still try build ORMs around RDBMS …
right?
Actually, its not about OO db engines at all, its more like a document based storage model – think Lotus Notes. And really, thats what a NoSQL concept is… its not data in a relational set of tables, its documents that are easily stored retried and access. Documents that make up the representation of the exact data you want to present to the user…
Simply stated, SQL and relational queries translated to Web pages or Web based applications are often times overkill and many times performance related problems. When you’re running huge queries with lots of joins and have to bring back a result set of thousands of records, it becomes not only a question iron you can throw at the problem, but how good are you at optimizing SQL. Not to mention the notion of iterating record sets and keeping track of that… SQL and Web although very much the “norm”, is a concept that is starting to fall out of favor for high volume, scalable applications.
NoSQL completely removes the notion of having to query and read a result set and deal with it.
MongoDb, or document based storage, although not as fancy around the query and relational way of asking for data, its far more analogous to how you tie a Web page to data. JSON notation was designed around client side JavaScript for a reason – it binds well to the objects on the screen, and its easy to manipulate that DOM within the browser.
If you’ve done SQL, PHP, JavaScript and HTML (i.e. LAMP), you know what its like to have to cobble together simple elements of a queries results to a page and not only display that page, but also ensure that the data is bound to your Web pages through the DOM on JavaScript.
Having been one of the “huge queries with lots of joins and have to bring back a result set of thousands of records” folks … in a former life I can say that it can be VERY tricky to optimize a database well and keep it that way (except we had about 8 TB of data and growing like mad and still had to insert & query live - I forget how many rows the big table had but it was several billion)
Sometimes you need to own & operate the hardware as you need to be able to distribute tables across physical slices on HD’s - somthing a hosting provider is not going to let you do. Or to partition tables across many disks & processors.
That’s not something most folks are familiar with.
I’d have to go back & reacquaint myself with it for Sybase & Oracle - and I’d still probably do it wrong its been so long.
But done well you CAN make a relational db fly.
Mongo & other noSQL db’s have places where they excel.
And they have places where they’ll suck.
Use them in the right places for the right things 7 you CAN do some very nifty things.
Use them in the wrong places and you’ll hate yourself.
The same can be said for trying to use a relational db in a place where a nosql database is really the right answer.