On Mon, Nov 30, 2009 at 12:29 PM, Mitch Pirtle wrote:
> This is what REST was intended for.
>
Keep in mind, by setting up another vector to get/modify data from your
database, you are also setting up another vector of data access you have to
secure.
I would only consider REST if your looking to
This is what REST was intended for.
You don't need to limit yourself to one database; and you don't need
to tie to any specific language. Scale shouldn't be limited by a
single database either...
By providing a REST API to your data, you push the concept of stored
procedures up the stack, making
Hi Matt:
>> All of them work and they're all pretty much the same when it comes to
>> the programming language layer.
>
> Except for when the programmers you're working with don't want to/aren't
> strong at writing SQL. Which is the case here, and I need more to do,
> hence wanting to put som
On Mon, Nov 30, 2009 at 5:44 AM, Jake McGraw wrote:
> Limit you to a specific database, the same database that thousands of
> companies successfully use for handling billions of transactions every
> day? I'd say the likelihood of you switching databases later in the
> application life cycle is sli
On Mon, Nov 30, 2009 at 3:30 AM, David Krings wrote:
> m...@atopia.net wrote:
>
>> So that has made me want to use stored procedures, but that will limit us
>> to this specific database software (mysql).
>>
>
> The question is if this is a problem. In my experience, stored procedures
> can add pe
Daniel Convissor wrote:
Whether it's in the database or in PHP, changing DBMS'es requires
recoding some aspects of the project. So put things where they best
belong. In the case you're proposing, a stored procedure is the right
way to go.
I would add that stored procedures also allow you su
All of them work and they're all pretty much the same when it comes to
the programming language layer.
Except for when the programmers you're working with don't want to/aren't
strong at writing SQL. Which is the case here, and I need more to do,
hence wanting to put some of the DB logic in th
Hi Matt:
> As an FYI, I've done this 3-4 different ways in the past, where the DAL
> was in stored procedures, a "man in the middle" code approach, and inside
> shared libraries. The problem with shared libraries right now is that
> there are multiple front ends, and even if they are in PHP,
The question is if this is a problem. In my experience, stored procedures can
add performance and allow for code to run on a different server than the web
server. But, if the expectations are to use other database platforms as well
you may need to take that into consideration. You may end up wri
Whether it's in the database or in PHP, changing DBMS'es requires
recoding some aspects of the project. So put things where they best
belong. In the case you're proposing, a stored procedure is the right
way to go.
Hi Dan,
Would the stored procedure route work best for all INSERT/UPDATE/DELET
Hi Matt:
Whether it's in the database or in PHP, changing DBMS'es requires
recoding some aspects of the project. So put things where they best
belong. In the case you're proposing, a stored procedure is the right
way to go.
See you,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O
On Mon, Nov 30, 2009 at 2:00 AM, wrote:
> Hi all,
>
> I'm working on a new project and I'm having a bit of trouble deciding what
> should go in the code vs. Database for this project.
>
> The database is a forum type schema, so there are a lot of transactions going
> on. For instance, when a re
m...@atopia.net wrote:
So that has made me want to use stored procedures, but that will limit us to this specific database software (mysql).
The question is if this is a problem. In my experience, stored procedures can
add performance and allow for code to run on a different server than the we
r instance, which creates a new
account, and can be called no matter what the front end code is.
M
--Original Message--
From: Tim Lieberman
Sender: talk-boun...@lists.nyphp.org
To: NYPHP Talk
ReplyTo: NYPHP Talk
Subject: Re: [nyphp-talk] Database vs. Code
Sent: Nov 30, 2009 02:
Stored procedures have their place, but should generally be abstracted.
If you have multiple developers, make one of them in charge of
providing an API for the front-end developers. You probably want to
pick one of the more experienced developers, since everyone else's
code will be talking
Hi all,
I'm working on a new project and I'm having a bit of trouble deciding what
should go in the code vs. Database for this project.
The database is a forum type schema, so there are a lot of transactions going
on. For instance, when a record is inserted into a post table, two counters
els
16 matches
Mail list logo
