Comment by ilaksh | Hacker News Reader

Comment by ilaksh | Hacker News Reader

On your home page you imply that you can automatically OCR arbitrary handwritten receipts into an analyzable format.

No one can do that. That is your problem, not MongoDB.

As far as aggregation, use the new Aggregation Framework http://docs.mongodb.org/manual/tutorial/aggregation-examples...:

    db.zipcodes.aggregate
      $group:
        _id: "$state"
        totalPop:
          $sum: "$pop"
    ,
      $match:
        totalPop:
          $gte: 10 * 1000 * 1000

As far as "losing the independence of your data access paths", no you don't. You are free to use linking instead of embedding wherever you want. http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesi...

MongoDB doesn't have a built-in full text search? So what. Most systems with large amounts of text to search do not rely on the text search capabilities built into relational databases anyway. People use actual full-text search engines like Lucene/Solr, Sphinx, reds, etc. Having said that, if you just wanted to support lowercase keyword queries with MongoDB, would it really be so hard to extract and store lowercase keywords from your text, as suggested here? http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mong...

If you are trying to add four 1s and get '1111' instead of 4, that is an error in your application code which has nothing to do with MongoDB. Very common problem with JavaScript. If it is JavaScript, try finding the code where you are attempting numeric addition and change it so that instead of saying for example 'total += newNumber' it says 'total += (newNumber * 1)' .

"On your home page you imply that you can automatically OCR arbitrary handwritten receipts into an analyzable format. No one can do that. That is your problem"

Jeez, lay off the confrontational tone. He doesn't say anything about OCR. Maybe he's using humans to do data entry? In any event, it's completely irrelevant to the topic of databases.

I notice you ignored all of my several very specific points directly related to his issues with the database system and your only comment was a criticism about the tone you perceived.

OK, maybe he is using humans to do data entry. The home page to me implies that the process is automatic, but I guess it doesn't rule out the possibility of humans doing data entry when he says 'tag and categorize'. But if he is using humans to do data entry instead of some automatic OCR, that is still his main business problem, rather than MongoDB. The application is relevant to the database discussion, and Hacker News is about all aspects of startups.

It's because I have nothing to say about the database stuff. Why are you so adversarial? I'm not here to cross swords with you; I don't have an opinion on the matter.

But I did notice your rudeness, and you're now being rude to me. Totally uncalled for.

I was not rude to the poster. I corrected him as far as his misguided complaints about MongoDB and the main problem for his business. That is the only way to help him.

I was definitely not rude to you either. You suggested that my comment was irrelevant, and I pointed out that my comment had a lot of relevant content in it whereas by your own definition of relevance your comment had none.

We don't do OCR, we have people who scan the documents if you snailmail them to us (or you can upload the scans directly to your account, email them in etc.) and then convert these images into queryable data with special emphasis on receipts (also invoices, bills, bank withdrawals, etc) and business cards. It's a service that our customers are happy to pay for, so I think I'm not quite getting your point about why this model won't work.

Had it been any one the issues I've pointed out, I would be quite happy to work around them. I do that routinely with other pieces of technology that do 95% of what I want. However, the hits kept coming. At the same time, I was using Postgres on another project and the question was begging to be asked - if I am going to run extra services like Lucene and do extra work to achieve full text search, what am I getting in return? And I am sorry to say - case insensitive search is quite a basic feature.

As for the 1111 issue - I admit it can be fixed. But the fact still remains - there's no way I would face this problem with Postgres. So why not just switch?

Postgres is a really nicely thought out and well executed database. And don't get me wrong - I am not building a system designed to operate at stratospheric scale. That would be premature in my opinion.

Thanks for taking the trouble to comment.

Reply on news.ycombinator.com