I'm writing a web application in Symfony for the first time, so I have a question regarding the use of Doctrine vs. Stored Procedures.
My background is in Java server-side, so I wanted to know what the pros and cons are for using stored procedures, versus using simple Doctrine code to get things done. At the most basic level, let's say that my Symfony web application is used for management, while there's another engine (which might or might not be written as a Symfony component, or indeed not in PHP at all) which retrieves configurations from the database for distribution or whatnot. Here I can see where stored procedures might be handy: both code bases use them to query and access data, while neither are preoccupied with the actual schema. If there's a change to the schema (adding a column in some table, for instance), then I'd only have to change the SRPOC, and nothing else, whereas if I had been using code in both engines to access data, I'd have to change them both to match the new schema.
Any comments? Or did I take it too far?
Thanks!
-DBG
If you don't use doctrine, you loose database abstraction, and object mapping. And this is a major loss. If you need third party apps integrations, you shouldn't let them interact with your database. Rather, provide a web service for them to read/write data via JSON, for example. This way you can change your database schema and have control over third-party apps.
Related
I'm staring to build a system for working with native languages, tags and such data in Yii Framework.
I already choose MongoDB for storing my data as I think it feets nicelly and will get better performance with less costs (the database will have huge amounts of data).
My question regards user authentication, payments, etc... This are sensitive bits of information and areas where I think the data is relational.
So:
1. Would you use two different db systems? Should I need them or I'm I complicating this?
2. If you recommend the two db approach how would I achieve that in Yii?
Thanks for your time!
PS: I do not intend this question to be another endless discussion between the relational vs non-relational folks. Having said that I think that my data feets mongo but if you have something to say about that go ahead ;)
You might be interested in this presentation on OpenSky's infrastructure, where MongoDB is used alongside MySQL. Mongo was utilized mainly for CMS-type data where a flexible schema was useful, and they relied upon MySQL for transactions (e.g. customer orders, payments). If you end up using the Doctrine library, you'll find that the ORM (for SQL databases) and MongoDB ODM share a similar API, which should make the experimentation process easier.
I wouldn't shy away from using MongoDB to store user data, though, as that's often a record that can benefit from embedded document storage (e.g. storing multiple billing/shipping addresses within a single user document). If anything, Mongo should be flexible enough to enable you to develop your application without worrying about schema changes due to evolving product requirements. As those requirements become more clear, you'll be able to make a decision based on the app's performance needs and types of database queries you end up needing.
There is no harm in using multiple databases (if you really need), many big websites are using multiple databases so go a head and start your project.
At my work we have two separate sites that are very closely related. One of them is a ASP/MSSQL site and the other is a PHP/Postgres site.
I want to create a REST API that everything from now on is built on top of. I would like it to be tied to both DBs so that it can be a a single point of retrieving and setting data.
I was thinking of using a DBA like Doctine to keep from writing queries in two different syntax. In the same system is it possible to tie parts of Doctrine to the MSSQL and other parts to Postgres?
If so, how? Any other thoughts on design are welcomed.
Within your application framework, you need to configure two separate entity managers, each of which will connect to a different database. More on entity managers at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/configuration.html
The core architectural pattern is that your models are plain PHP objects, and the entity manager (Data Mapper) will read the mapping configuration to know how to map the models to a database.
If you're writing a REST based API it shouldn't really matter what the DB backend is. For example, if you write your API in a combination of Django and tastypie, you could simply swap out a settings.py config to work with both Postgres and MySQL... or even MongoDB if you so chose
The point is, a REST API is a generic solution that can be used by a multitude of languages, you should chose a framework that allows you the same flexibility in DB backends to implement.
A friend of mine and I just started an own project to learn about the newest and most future relevant web techniques: we decided to build an own object-oriented content management system with enhanced functionality like the community-points function on this site.
Using PHP as developing language and MySQL as database – which seems to be the standard database solution for everything on the internet – we quickly got into trouble saving our objects into the database, especially the references between objects. As a first solution we worked with table that - as we know now - are called "joints".
But then I started a research on how to solve this problem. Here's what I found:
there are object-oriented mapping solutions for relational databases, also for MySQL & PHP
there is a special database model designed for solving this particular problem: the object-oriented database
the object-relational database, a hybrid model that basically is a relational database with special handling for object savings
Since I don't want to start one more best-database-model-debate, here's my specific question:
Which of all solutions I have mentioned and you know from elsewhere is the one that's well supported from enough and not too expensive web-storage providers and is good enough for "basic" object-oriented functionality and thus be good choice implementing an object-oriented content managment system? (Again, the most painful thing we have crossed til now is the lack of referencing other objects in the database.)
Recommandations on particular database types are highly welcome!
You can try any "NoSQL" database, they are not relational. For example, MongoDB. Mongo stores data in BSON format which is like JSON and in PHP you can easily handle JSON data. You can find information about NoSQL databases at http://nosql-database.org/ and take a look about MongoDB as well http://en.wikipedia.org/wiki/MongoDB
Sorry in advance if my wording is wrong because I'm not quite sure how to explain what I want, so I'll just describe the end result.
I have a php based excel tool called socialcalc(it was wikicalc before). I want to allow users to connect to a database and pull live data onto the sheets(so they can run calculations on it).
I understand that for sure socialcalc will have to query mysql but I'm trying to figure out the most effective way. Is it better to allow it to query it directly? or should I have it query the database an get an xml file as a result? Or what other ways would you suggest is a efficient and secure way of allowing read access to the data?
We're building alot of the this ontop socialcalc from scratch so pretty open to all solutions but ultimately, we want this to power other services.
Update: to clarify, I am looking for suggestions on using SOAP/XML over say directly querying the database or using HTTP POST/GET,etc..which type of service layer would you suggest or what are the factors to consider when choosing?
"Simple is better than complex."
You could certainly implement a Web Service layer between your application and MySQL, but ask yourself why you would want this. You might want it because:
You plan on changing backend systems at some point in the future and don't want to have to refactor business logic in the front-end application
You want to expose your backend data to other applications and provide a common interface for doing so
You want to implement smoe sort of caching/persistence strategy in the middle tier
All of those would be valid, good reasons to use a Web Service layer between your application and your database. Certainly there are more valid, good reasons as well.
If you can't think of a reason why you should implement a Web Services layer, then don't, it's that simple. You can always decide to later when there is a good reason.
EDIT:
So you've decided to go ahead with the Web Service...congrats! I think in that case you should look at two key frameworks to save you a lot of time:
Get a good ORM framework that can generate the vast majority of your CRUD logic. Doctrine is a popular choice for PHP.
Use a Web Services framework for implementing your interfaces and business logic. I've done this in the past using the Zend Framework, as they support both XML and JSON payloads via REST. XML and SOAP are great if you need strict data validation requirements, but if you're the only one consuming your own Web Service, you don't need to impose such limiations on yourself, as you know your requirements. In that case, JSON should be sufficient.
By the way, I've discussed RESTful services via Zend in another previous question:
lightweight RESTful PHP server
I think the best approach is by using a step-to-step action.
Sep one
Let the user choose the data he want to implement in his excel sheet. How to do this is up to you.
Step two
Submit the choise of the user to a own created SQL API. This API will check the input for injections and so on and will do all the query en retrieval of data.
Step three
Send teh retrieved data to a class which will create the excel file.
Step four
Send the created excel file to the user.
The most importent part of this is the SQL api. This is a class which handles all the input from the user and communication with the database. It can use normal SQL statements but you cna use it to validate all the data.
Hopefully this is some use for you.
I'm creating a new web application (Rails 3 beta), of which pieces of it will access data from a legacy mysql database that a current php application is using.
I do not wish to modify the legacy db schema, I just want to be able to read/write to it, as well as the rails application having it's own database using activerecord for the newer stuff. I'm using mysql for the rails app, so I have the adapter installed.
How is the best way to do this? For example, I want contacts to come from the old database. Should I create a contacts controller, and manually call sql to get the variables for the views?
Or should I create a Contact model, and define attributes that match the fields in the database, and am I able to use it like Contact.mail_address to have it call "SELECT mailaddr FROM contacts WHERE id=Contact.id".
Sorry, I've never done much in Rails outside of the standard stuff that is documented well. I'm not sure of what the best approach would be. Ideally, I want the contacts to be presented to my rails application as native as possible, so that I can expose them RESTfully for API access.
Any suggestions and code examples would be much appreciated
This really depends on how esoteric your legacy db is. This affects the solution considerably. If your legacy db is quite similar to Rails conventions then using a model with a few customizations will probably prove as the best approach. However I've heard of people who wrote a script that constantly reimported data from the legacy db into a new db - the whole structure of the db was so wrong that approach was worth it.