Lets come back to xojo world. From my experience, you will use mongo for big data or data warehouse, something that you will not do it ,using Xojo tools. For business applications like crm/erp/etc you will use RDBMS. Maybe, you can use nosql Object Database like Wakanda db and some other java db, but again forget the performance. Of course it is more easy to write OO code,rather than a complex SQL queries. Its your choice.
[quote=34892:@Ruslan Zasukhin]
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]
Yes, I’m using JSON as it’s the preferred data for document oriented NoSQL DB’s like Couchbase 
It’s perfect for my purpose, you just throw everything add it and it’s quickly found through the key (which doesn’t even has to be unique) and gives you instantly access to the whole JSON document. So it’s more like having a lookup (hash) table and then find the exact folder (like the one that HR most likely has about you) with all the information about you that they could put together. Your HR folder is different from many other peoples folder, again an advantage as you don’t have to give one rigid structure and fill it with NULL values.
I like it, once you get the grip with NoSQL DB’s (like storing data in a very wide form but not deep) you will like it
Andreas
I think, the discussion here misses a couple of important things, none of which have something to do with technical or structural concepts.
IMO there are 3 points, why NoSQL databases like CouchDB, CouchBase or MongoDB are interesting for developers (especially for web-developers or iOS/Android-developers):
-
The mentioned DBs support auto-sharding or auto-replication, that means scaling the db-backends horizontally (clustering) is a no-brainer. This is especially important, if you start with a small user-base and suddenly or (un-) expectedly gain lots of users.
-
(Multi-directional) Syncing JSON-documents is already integrated on DB-level. So a web-dev can sync their stuff bi-directionally without a big hassle. Syncing gateways and iOS/Android clients already exists (and since the document is JSON, you can natively communicate with the databases e.g. via a built-in REST interface).
-
Adding more concurrent users is cheap. E.g. CouchDB is licensed under the Apache license, which also permits commercial usage without additional fees. This is where commercial RDMS get expensive very quickly. So adding more users is just covering costs for load-balancing or adding a couple of more nodes to your existing database-cluster.
For me #2 (and most likely #3) are the deal-breakers for commercial RDBMSses, especially if you’re an app developer on budget.
Can MongoDB be accessed from Xojo?
There is no plugin or public code that accesses it that I know of.
However, it should be possible to write code that does.
How would I go about doing that? Any sample code?
I’d grab the Python or Ruby adapter that already exists for Mongo & convert that to Xojo
It’s what I was planning to do when I get some “free time”
Free time - what a notion hahahahahahahahahahaha 
And how do I convert that to Xojo?
not without writing what MongoDB (inc) calls a driver. it is their interface between your code and their DB. They have several drivers out there for lots of programming languages. Just not RB/Xojo. They have a SDK on writing a driver on their site that is free.
if you know another language (Norm mentioned ruby & python) you can use their driver to help you write one for Xojo.
I would love to see a driver but I dont have the time to write the code.
[quote=38906:@Andy Fuchs]I think, the discussion here misses a couple of important things, none of which have something to do with technical or structural concepts.
IMO there are 3 points, why NoSQL databases like CouchDB, CouchBase or MongoDB are interesting for developers (especially for web-developers or iOS/Android-developers):
- The mentioned DBs support auto-sharding or auto-replication, that means scaling the db-backends horizontally (clustering) is a no-brainer. This is especially important, if you start with a small user-base and suddenly or (un-) expectedly gain lots of users.[/quote]
Hi Andy, glad to see/hear you 
About sharding. Let me ask … Is this so super-hard to implement feature?
Yet in 2007 year, one guy - Stefan, have told us, that he have implemented it self before Valentina Server. In few hours.
Sharding idea is very simple. User comes and from its login is calculated hash-result.
Result can be 1 or 2 bytes usually INTEGER. This give you ability to choose 255 or 65535 computers behind.
Then query go to that computer.
Any experienced enough developer can write such “dispatcher-server” quite easy.
As says Wikipedia - such sharding can be implemented for ANY DBMS.
MongoDB have put this as bult-in feature.
We have think here – thanks to Antonis :-), and we think this can be good addition to Valentina Server also.
yes, when it is built-in, then less job for developer.
Note also, that such horizontal scale scarring, can be used not for all tasks.
And it is good for such common Web Tasks as “Online Store”, may be RPM.
When “User XX” comes to online Store, he see only his own orders. He do not see and should not see orders of other customers.
This is why THIS task can be splinted to N computers. “User XX” always will be sent by hash function to e.g. computer 38.
So what I want underline here, I hard believe when people say: Mongo is superb for sharding, but e.g. mySQL/PostgreSQL no.
My friend says that MS SQL have such features many many years ago., And very advanced and complex. I self did not see.
[quote=38906:@Andy Fuchs]
2. (Multi-directional) Syncing JSON-documents is already integrated on DB-level. So a web-dev can sync their stuff bi-directionally without a big hassle. Syncing gateways and iOS/Android clients already exists (and since the document is JSON, you can natively communicate with the databases e.g. via a built-in REST interface).
- Adding more concurrent users is cheap. E.g. CouchDB is licensed under the Apache license, which also permits commercial usage without additional fees. This is where commercial RDMS get expensive very quickly. So adding more users is just covering costs for load-balancing or adding a couple of more nodes to your existing database-cluster.
For me #2 [/quote]
Andy, before I have express point of view, that JSON and XML are transfer-data-formats, but not storage-data formats.
It is absolutely bad idea to put it as is, as “document” into DB. Except as “Lazy Job” for developer
Can you argue? 
Also have you see that PostgreSQL 9.3 have added a lots of thins to support JSON?
Its hard image that “a developer on budget”, will build solutions with 255-5000 physical computers, no?
postgreSQL do not add costs on connections, yes?
mySQL and Valentina Server add at current prices 399$ per node it seems.
I think after we will add sharding we will provide special price for cluster.
Norman, I understand’ about the driver. But how do I access it from Xojo? That’s the part I don’t understand. Let’s say I want to access the MongoDB operation db.data.find(). How do I call that from within Xojo using the driver?
I think Norman means that it need write new plugin for Xojo, which follow to similar plugin of Ruby or Phyton.
Although this cannot be so simple, because Rube have features missing in Xojo language.
But there is no such plugin right now.
Ruslan, when you get a sec I could use your help over here.
[quote=38940:@Ruslan Zasukhin]Andy, before I have express point of view, that JSON and XML are transfer-data-formats, but not storage-data formats.
It is absolutely bad idea to put it as is, as “document” into DB. Except as “Lazy Job” for developer[/quote]
Yep, but that’s exactly the nice thing about it
But that was not my point.
There’s a very different problem for lots of developers (especially web-developers): How can I sync my data back to the server-db? Lots of times a developer spent huge amount of times to sync data back to the server. This is especially true, if you allow adding records while the user works offline and a good way is needed to sync and also solve conflicts. CouchDB adds pretty nice support for that, which reduces the workload for the developer quite a bit.
And exactly here’s the big benefit: Since lots of developers need their app to communicate with a server and/or a HTML-page, you must find the least common denominator when it comes to selecting a communication scheme. This is not a problem in a native app, but nowadays browsers don’t support lots of data-formats (or databases). Here’s where JSON comes into play: Using a random browser you CAN generate arbitrary JSON-documents, save these documents (offline) to a key/value store (on localstorage or indexedDB or whatever) and send those documents to the server later easily. And since synching features are already implemented in CouchDB-server, it is a no-brainer for the developer. This reduces the amount of work dramatically. And THAT’s the whole point: The developer is able to produce a true cross-plattform app easily. Nobody cares, if this produces a semantically perfect database on the server or not…
The solution to that would be to add syncing to Valentina-Server. Or - even better - you need a Valentina-Syncing-Gateway (since the Valentina-Server should not be directly accessible from outside) which contains a light-weight database-engine and thereby would be able to cache the sent database-updates (just in case the database-server is busy or unreachable at the moment) AND can push back the results of the sync. (btw. this is something Couchbase currently works on (http://www.couchbase.com/communities/couchbase-sync-gateway). Adding this would make Valentina the Killer-DB
No - I did not, but merely because I haven’t have too much time lately to play with all these things.
[quote=38940:@Ruslan Zasukhin]Its hard image that “a developer on budget”, will build solutions with 255-5000 physical computers, no?
postgreSQL do not add costs on connections, yes?[/quote]
No, but it’s always good to know, that there’s a cost-friendly option, if your userbase jumps from 5 to 30000. Creating a Couchbase-cluster - for example - is a no-brainer. Adding a replication node just takes a couple of minutes - and you can add as many as you like, which (again) is something that is good to know - whether you need it or not.
[quote=38940:@Ruslan Zasukhin]
mySQL and Valentina Server add at current prices 399$ per node it seems.
I think after we will add sharding we will provide special price for cluster.[/quote]
IMO you should think about syncing BEFORE sharding - this will open up a much bigger user-base for you. If you want to discuss this - you have my mail-address
Norman, you seem hesitant to supply an example. Am I asking for something that is an additional cost? If so please let me know. I’ve looked at the Xojo examples and I can’t find anything that pertains to my question.
By default there is no connection to NoSQL. Norman would have to write the driver for you.
I think he might do that when he has free time
He says sleep is overrated anyways.
[quote=39123:@Robert Kamarowski]Norman, you seem hesitant to supply an example. Am I asking for something that is an additional cost? If so please let me know. I’ve looked at the Xojo examples and I can’t find anything that pertains to my question.
[/quote]
Such a driver does not design or write itself. There’s nothing like it in Xojo right now. See the extensive discussion above for all sorts of ideas about how one might think about approaching it.