Hacker News new | past | comments | ask | show | jobs | submit login

This makes sense for e.g, when you want to make your database content available for search (via elasticsearch) - for this you may want to push the raw DB rows.



Again it doesn't really make sense because you are tying the physical DB schema to the search engine schema.

Your application domain model should be at the centre of your architecture not the physical database model. For example storing a User object rather than a row from a User table.

I understand why a database company would see a database as the centre of the world. But it really should be your application. Especially if you want to use PostgreSQL and InfluxDB for different domain types and yet have both indexed in ElasticSearch.


No.

The application domain model can be buggy and full of holes. The data store is the source of truth.


Couldn't agree more.

It's also pointless to try and convince someone who thinks otherwise either, I found it better to let the those developers shoot themselves in the foot and learn the hard way. It's the only way they'll learn.


You are right that the ES and DB schemas shouldn't be directly tied together. That is why I have specific DB functions that output the correct format for ES and only those functions need to change if the ES or DB schemas change. It is a much simpler way to do it then to have application worry about it in my opinion.


You're gonna have a lot of fun once you transcend beyond 'single central application' and have multiple apps interfacing with your data.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: