Hi. I'm in a project deving a conversational agent (bot) product where my client will be able to register products that they sell. I know that mySQL is perfectly good for it. In the other hand I want to store conversastional data such as general text exchanged, dates, product lookups, etc... so I can extract statistics from it later. Where I know mongo excels at.
I don't know if the cost bennefit of changing mySQL for mongoDB is good for me because servers, finding devs that can code with mongo in a near future when my project expands may be difficult, etc...
Shoud I pick one or use both? Does anyone have experienced a situation like that or have some tips?
Well your statement is correct. Mongo is much better for your project. However coding with Mongo can be challanging if you do it for the first time.
Lucky for you there are packages with the codestyle of Eloquent for Mongo. This way you actually don't have to learn anything new to start with the code. Another option is of course writing your own code that connects with Mongo. It completely depends on the size of your project and how far you want to take it.
Both packages below can help you out. Go through both of them, they offer the same basic functionality but they differ on advanced options.
I already messed around a bit with mongo on a test project of mine using eloquent from jessengers, it's pretty nice.
Would you advice me to use mongo througout the entire project? I was thinking of using SQL for the login, client and product modules since its inheretly relational. I've read that deving relational with mongo can turn into pain as the project gets more complex...
@casanova I would consider using both. Treat your audit trail as a separate service with a simple RESTful API. Moving forward you can cherry pick your BI tool.
@casanova I would split them in this case. Your needs and goals are clear here, so it would be wise to split them up here. Like @CJJ said, you can build a custom API for it.
You even might even make it a separate service or application which you can use in your application ;) If you build the Mongo part and it's data with a separate API and/or in a separate application you can reuse the data on multiple places and you don't have to mess with multiple database connections in one application
To clarify my previous post and touch upon @bobbybouwmann comment; I am definitely suggesting you build two separate applications.
At my place of work we have a generic NoSQL auditing solution servicing many applications and microservices. We use AWS DynamoDb and a Lambda function with a BI tool. Our technology stack may differ slightly but it's not important. And as more applications come online you can plug them into the same solution.
Your boss can have all the statistics, real time reporting, charts and graphs they ever dreamed possible whilst encapsulating MongoDb in a single service.
