Slashdot Mirror
Programming PHP
This book begins as most O'Reilly "Programming" books do: with a brief introductory chapter. In Programming PHP, this chapter is very short, so don't look to this book for a gentle introduction. On the other hand, this is the perfect book for you if you are just looking to learn a new scripting language. The following chapters go over syntax, data types, built-in functions, etc. These chapters are a little dry, but move quickly and effectively demonstrate the unique features of PHP (as compared to other scripting languages).
Of particular interest to programmers who are interested in expanding their horizons to developing dynamic web pages are the chapters on PHP web techniques, security, and application techniques. The web techniques chapter gives a quick overview of HTML and the GET and POST methods (and why you would want to use one or the other). It then covers a lot of useful tips and tricks that may be foreign to someone who has done little or no web development. Topics such as getting server information, form processing, sticky forms, file uploads, document expiration, and authentication are covered. It ends with an excellent discussion of maintaining state from page to page and visit to visit, covering cookies and PHP's (very cool) session support.
The security chapter covers standard things you want to keep in mind when creating dynamic HTML. No surprises here, but it is always good to be reminded. The application techniques chapter starts with a collection of best-practices, tips, and tricks to make your development process easier and better. It concludes with sections about error handling and performance tuning. As with the security chapter, there is nothing here a good programmer doesn't already know, but you can never hear it too many times.
I think this is a great book for programmers who want to start developing dynamic web sites with PHP. It gives a detailed overview of PHP, lots of valuable tips, and a good sense of PHP's strengths.
As someone who has written a lot of code, but only a little CGI, I really liked the chapters that discussed application development techniques specific to the web. Along those lines, not much time is spent on standard coding techniques, so if you want to use PHP but have never written any serious code, you may want to look elsewhere for an introduction. For the rest of you, just think, you may never have to use CGI.pm again.
The index seems adequate, although I must admit I did not use it much on the first read-through. The book is so well organized that, when reading it, you do not have to flip around much. Perhaps someone who has used this book as a reference can comment further on the quality of the index.
Contents are available on O'Reilly's page LinksSee Rasmus's page for links to where you can buy the book (maybe he gets a kickback for the link). Of course, you could always go to a local bookstore and purchase it.
You can purchase Programming PHP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Isn't this a contradiction:
This book provides good programmers who have never used PHP enough information to do serious web development using PHP
and
so if you want to use PHP but have never written any serious code, you may want to look elsewhere for an introduction
So is it good for newbies or not?
Most people would die sooner than think; in fact, they do.
It redefines the paradigm of online programming. Programming PHP, like PHP itself, marks a watershed in programming history. Generations from now technology historians will divide the time line into two periods: PPHP (Pre-PHP) and PPHP (Post-PHP). The PHP language, just like the book describing it, is beyond compare. Coupled together they have created a force for Good that rivals Superman, God and Scooby Doo all rolled into one. My next child is going to be named "PHP Programming Lastname".
This book provides good programmers who have never used PHP enough information to do serious web development using PHP
Those who are experienced with another language will find this book useful for picking up PHP.
so if you want to use PHP but have never written any serious code, you may want to look elsewhere for an introduction
..if, however, you don't have experience in any programming language, you'd be best to find a book that spends more time covering coding basics.
According to NetCraft, there are more PHP web sites than ASP.
http://twitter.com/onion2k
As a semi-competent Perl hacker I found PHP very easy to pick up, and I imagine the same would be true for anyone with some degree of coding experience. The only reference I find myself using regularly is the excellent PHP website which provides a pretty decent tutorial and a thorough and searchable command reference. Combine that with the fact that the manual is annotated by PHP users and the only reason for having a dead tree reference is to have something to read in the bath.
Still, buying it does at least give Rasmus some money...
"Are you being weird, or sarcastic?" said Emma. I said I didn't know because I get the two feelings mixed up.
Lacking x feature or n widget doesn't necessarily stop businesses from using something, it just keeps them from using it for everything.
Chris Tembreull
"My karma just ran over your dogma."
Are you kidding?
I work at a law firm full time, and that is all we use.
PHP is all I get requests for now, for outside work. (Actually less and less ASP crap, and no Cold Fusion)
"If you have done 6 impossible things this morning, why not round it off with breakfast at Milliways" -- hhgg
While I am sure that this is an excellent reference for PHP users, I'm sure I'm not the only one who thinks there is little point in buying a book on PHP when http://www.php.net/manual/ exists.
Though i'm not sure how they got those numbers it does show an interesting trend. PHP has been on the decline this year.
Also this doesn't relate well to other non-apache based tech's like ASP or ColdFusion.
-Jon
this is my sig.
The other day while I was waiting for a friend a Barnes and Noble, I picked it up only to put it back on the shelf ten minutes later. Usually I buy every Oreilly book for technologies that I use frequently, but I figured that there is probably very little in the book that PHP's excellent online documentation doesn't provide.
I could have sworn there was CORBA support (able to compile in CORBA support, anyway) but I can't find reference to it now. Has it gone?
creation science book
Tell me about it. PHP is good if you are running a small MySQL-based webzine but if you're doing e-Commerce or anything database-intensive, as most high-volume sites show, use ASP, JSP, or precompiled-binaries (in the case of eBay's ISAPI interface).
ASP is for people who don't mind paying for a good programming environment.
and help pay Rasmus for his PHP, which is pretty cool. He gave a great tutorial at our university and parked PHP development all over the place. I love Perl like Madonna loves dick, but PHP is a good tool to have in the carpenter's box for many one-off projects and tasks that simply don't require Perl.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
No, nothing has everything. On the other hand, "business" will do without almost anything as long as the task at hand gets done. PHP is not only excelent for business, it is wildly used in large e-commerce sites all over the world. Along with Perl, Python and Java servlets, it is one of the key web development technologies. It is very fast and very responsive. The lack of one or other feature may be a local problem, but it is not a general problem that allow you to classify it as "pointless"
Only inexperience makes one mix the "must have" column with the "nice to have" column. Or excessive press release reading. I have been using Java (Tomcat) and Python (by the way of Zope) in my recent projects, but I used PHP for years and it has always been adequate for small and large projects.
What makes it worse is they are trying to make it more OO by re-inventing the wheel. If they used an OO language underneath, they can make it more OO like.
PHP always acted like a complete hack of a language vs something that was engineered. Look at the database layer? No common functionality. Pear is cool and all, but by making the old calls avail, you allow users to still shoot themselves in the foot.
Sorry, bitter from trying to do enterprise programming with it.
-
ping -f 255.255.255.255 # if only
www.php.net/mysql_query
www.php.net/strftime
I've found this most useful: you only have to type a few more keys besides the function name to get the documentation, kind of like man pages.
I have also given a 'quickie' review about this book months ago on out little site. You can also find the thread on signalnine by clicking on the 'reader reviews' link, on the book information page.
spam, spam, spam, spam, e-mail, news and spam.
There is no denying that the php.net/manual site is a good comprehensive resource. I do get tired of people suggesting to avoid books and just use the online manual. Obviously, they both have their places.
:)
The first strike against the online manual is that it's not portable. Downloading in most of the portable formats loses the user contributed comments, which are really what make the online version as helpful as it is in most cases. Seeing how other people have worked around issues, or just posted small extra example snippets is often a lifesaver.
However, where books can come in useful is the depth. The biggest drawback of MOST PHP books is that they are thin on detail - sometimes a 500 page PHP book has less than 200 pages of 'useful' content, and often times its still elaborated examples of basic 'form submission' code. 200+ pages of reprinting the manual is often not useful for too many people. Yes, it's portable, but I don't need pages of mSQL commands, for example, printed in any book.
The few good books I've seen regarding PHP that are more in depth and less 'manuals' include the new Professional PHP4 XML (not perfect, but certainly useful if you need to do XML, although that's a moving target in PHP), PHP 4 Web Applications (from New Riders, kinda thin, but many good techniques over and above the usual PHP stuff) and a couple others which escape me. Probably only 20% of the books published actually contain useful stuff you won't find by combing the manual or various discussion boards.
Also, in defense of books, some people just learn better by being able to read and see examples (which is why the books should have more good examples and fewer filler pages of manual reprinting). Similarly some people do better with hands-on training than with forums or books, which (small plug) my company provides (http://www.tapinternet.com/php/).
creation science book
You have probably never used PHP seriously, so you can be forgiven for your fast words. PHP is used in large commerce sites and large content sites all over the world.
Actually, ASP is for people who don't mind being locked in one operating platform, a problem PHP, Java , Python and Perl don't have. For your small projects it may not be an issue, but as projects grow bigger and more expensive, flexibility (pointedly cross-platform) quickly becomes a fundamental issue.
Well, there is XML-RPC support as an extension (experimental) and there are several XML-RPC and SOAP classes available written in PHP.
I am writing a major web tools framework (see my sig), and I will be adding SOAP hooks for the applications as a whole and a SOAP engine as well (once the sample app is rewritten to be OO).
LedgerSMB: Open source Accounting/ERP
When I read your post, I thought of C++...
A complete hack of a language. It's cool and all, but by making the old calls available, you allow users to still shoot themselves in the foot.
At any rate, I always thought the point of a good programming language was to give me a good gun for hitting the type of target I'm after...but if I want to aim it at my foot, well, c'est la vie.
IIRC, ASP does not allow direct sockets access for security purposes. If you really want to manipulate connections like that, write a server-side ActiveX Control. That's the "right" way to do it.
I can read a book while I'm sitting on the back balcony, in a relaxed position away from any keyboards (yes, some Slashdot readers do step away from the computing devices from time to time). I can very easily annotate the book with this thing called a highlighter. I can even make notes in it with a special "pen" device.
Don't give me the expense argument either. Forty or fifty bucks for a good computer book is like an investment in your future employability. For most of us, this book will cost less than we'll bill for an hour or two of work.
If you don't like computer reference books, that's fine, but realize that for some of us, they're quite handy and worth the money.
Read the EFF's Fair Use FAQ
- xmlrpc: works
- SOAP (via http, https or smtp transport): works
- CORBA (ORBit / satellite): works
I've probably overlooked some more but it should still get you startedyou have moved your mouse, please reboot to make this change take effect
I think you are under the impression the "dotcom" style of software life-cycle (develop today, throw away tomorrow) is the market standard.
Well, it is not. In the real software development world, you don't plan for the next year, you plan at least for the next five years (more, if you are really smart). Or have you not noticed the Y2K panic was mostly caused by 20-30 year old software still being used in production environments?
There many compeling reasons to take cross-platform capabilities into account. There are measured data showing somewhere up the scale it is cheaper to buy a very expensive Sun or IBM machine than keep throwing Intel hardware at a problem. There is also the corporate climate changes and technological advances to take into account. And I am not talking just about Microsoft licensing problems, but also about the forseeable Linux future.
All in all, dismissing the possibility of platform exchange is a risk most large projects prefer not to take, specially because it is more and more an easily avoidable risk.
Being the first edition, it does have some quirks to iron out which I have forwarded to the author. For example, it may talk about one alias to a function but not another, which would be helpful for Perl programmers and the like (for example, split is an alias to explode and join is an alias for implode). There were also a few issues with some of the functions in the book where they mixed up the argument order. Also I felt they didn't put near enough time into optimization, whereas the Perl book spends quite a few pages discussing it (I think the PHP one maybe had one page on it). There were some small things they skipped over which could make a difference in huge projects (when to use "" and when to use '') and whether to do print "$a$b$c" or print $a,$b,$c or print $a.$b.$c, etc. But overall this *is* the best PHP book I have read and I do look forward to their next edition.
//m
PHP is certainly not intended to be a middle-tier language, which is where remote calls would be most useful. That said, there's no reason some time couldn't be invested to find a work-around. Many C libraries can be wrapped with ease and accessed from PHP. Find a C library that allows for RPC (or remote object calls) and wrap it. Nevermind the ease with which Java classes integrate with PHP (its dead-simple) and Java's well known RMI (et al) support, you should be set.
:)
As other posters have mentioned, PHP doesn't need to natively do *everything* - that just serves to bloat. But, it ought not *prevent* anything (which is Perl's mantra, too). For the most part, this is the case, especially with the Java integration. Between PHP and Java, if you find something that you can't do, I'd be most surprised. And if so - just use Perl
Cheers.
I think your view is unbelievably pretentious considering that according to this the U.K. had 3.7 million active businesses in 2001 and of them 99.1% were small businesses (under 50 employees).
And, according to this in the USA:
Also, small businesses...
- provide approximately 75 percent of the net new jobs added to the economy.
- represent 99.7 percent of all employers.
- employ 53 percent of the private work force.
- provide 47 percent of all sales in the country.
- provide 55 percent of innovations.
- account for 35 percent of federal contract dollars.
- account for 38 percent of jobs in high technology sectors.
- account for 51 percent of private sector output.
- represent 96 percent of all U.S. exporters.
Gee, now I see your point. You're right: PHP is useless to just about everybody out there.That said, I do have a gut feeling PHP is overcoming or overcame ASP.
It's simple to re-enable register_globals - just use ini_set() or make a .htaccess file.
Not good practice, but can certainly do it if needed.
It seems to me that web language books need to be split into two groups:
1. Web techniques
2. The language
Once one is familiar with typical web techniques and issues (form handling, state management issues, etc.), then many of the books seem redundant WRT web techniques.
The problem is that "Web Programming Techniques" would probably have to choose an actual language for its examples, so they figure they might as well put them together.
Perhaps Oreilly should split web language books into a language details book, and a "Web Techniques using X" series for those new to web issues (where X is a specific language). They could use pretty much the same material, but simply swap the language for that one.
Web programming issues are pretty much the same in ASP, PHP, ColdFusion, etc. If I need to pick up yet another web language, such as JSP, I don't want to waste book-size and eye-space on the same web issues, I want to get right into the specifics and uniqueness (gotcha's) of the particular language.
Table-ized A.I.
I've programmed in both ASP and PHP, started out using ASP. I've been doing more and more PHP programming by choice recently due to the performance benefit I've seen by using PHP.
I converted my personal ASP site over to PHP some time ago and noticed that it ran MUCH faster using PHP, page loads were faster, DB queries we faster, etc...
Comparing them side-by-side on a Windows machine, I've still seen better performance out of PHP than ASP, even ASP server side components. Plus the ability to call both Java and COM objects on the same page makes it a no-brainer for web development. (especially how long it took VBScript to get regular expressions)
Now ASP.NET and JSP, that's a different story... but PHP kicks ASPs butt every time.
"For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
Yeah, that's cause it's not a database layer. The database API is the one exposed by the database client library. Every API is different because every database vendor does something different. This is not the fault of PHP. Most languages FORCE you to go through some kind of abstraction (Microsoft has ADO and ODBC) which just does exactly what PEAR::DB does. But if you only use one DB type, or need some special functionality of the API, then for best performance and compatibility you'll want to use those base APIs.
I for one don't use PEAR::DB. I have my own database abstraction for my own projects which, of course, makes direct calls to the database. So I'm happy for the ability. (Same goes for the other API's as well) You can't shoot yourself in the foot using the database-specific API's.
Ok, layer is a word i use only because it should be seperated somehow.. perhaps i'll just use the word api. Fine, every DB vendor does things differently, but there is a LOT in common. How do you think perl's DBI layer works? They use dbd (iirc) for the specifics and interface it into dbi, a common ground.
The disadvantage of using the specific api's? Try switching databases and watch the chaos ensue
-
ping -f 255.255.255.255 # if only
The performance increase between using exposed and hidden functions is minimal. If you should want to write your own abstraction layer, it could be done on top of a common one. Say I don't like perl's DBI and i like procedural programming. I can write a layer on top of it. If I also want to, i can replace DBI using what DBD provides. And perl's method of db communication isnt' hidden by far. Just like php's module interface isnt' hidden, though VERY poorly documented.
PEAR::DB and ADO:BD are carpets which the dust has been swept under. By leaving them exposed, they allow people to make things more difficult. It's like putting a cardbord box over a gun in your house. Sure, the problem doesn't look like it's there, but you can easily find the gun and shoot someone.
What I'm saying, is that the mix-matched-names are bad. VERY bad. They show no relationship to a higher level of commoonality. There's no common prepare_statement(databse_handle,statement) type structure. Everyone does what they want. And if you have to switch db types, you have to relearn everything.
-
ping -f 255.255.255.255 # if only
I have really limited web experience but I have a simple need.
Basically, pdf files are generated in a directory. I need a user to be able to see all pdfs in that directory, be able to 'delete' the one he needs after he downloads it, and have the file really be deleted after 48 hours of being marked as for delete
I have *no* idea how to do this, but what little ive looked at says I need php
Would php be able to cover all of this, and if yes, would this book tell me how to do this?
Or should I learn another programing language first?
The ultimate network admin tool needs HELP!
Hehe, and here I thought I was being rude. I'm going to have to work on that. ;)
... but any good solution suite should be componant based .. sometimes the cost of supporting another platform is outwieghed by the cost of solving a small problem with enterprise technology (ie, solution overkill).
Seriously tho, I understand that peoples views stem mostly from their experience, but thats pretty much the golden rule of software: Even enterprise businesses have suitable uses for non-enterprise software. There is always a time and place for high load distributed multi-tier web applications, and PHP can be a little out of its element in really large deployment environments if developers treat PHP like its a stand-in for other enterprise web app platforms
The Right Tool for the Right Job; just dont assume the kinds of jobs you have to do have any intrinsic relationship with the size or worth of the company. Case in point: A small internet advertising delivery company will have a much greater need for performance and speed than a large company with thousands of clients on a web application. In this example, its the small company that needs the robust, extensible framework, while the larger company can probably get away with building their front end in PHP. And of course, many companies will need both (high performance servers with lightweight web front-end) so using both enterprise-style platforms and lightweight style platforms (PHP and Perl) is not uncommon in the same organization.
Anyhow, toodles!
"Old man yells at systemd"
> Pear is cool and all, but by making the old calls avail, you allow users to still shoot themselves in the foot.
Uh yeah, mostly because, as programmers, its our job to hold the gun. Not knowing which body parts to shoot, ours or otherwise is the sign of a bad programmer, not a bad API.
I like having the options. On portable projects, I can use one of the many abstracted db layers. On non portable, I can just rip through development with the mysql-specific apis.
If they didn't make the naked db-specific APIs available, nobody else could developer their own home-cooked abstraction layer. If you dont like Pear:DB, at least there are alternatives.
"Old man yells at systemd"
Don't fret, you're normal. Reading book-length material online is a real pain (literally).
/. runs a book review. (Why even ask if a book is "necessary"? That's not germane. A book is here because an author wanted to write it and a publisher bought it.) Some posters seem to take a book's existence as an affront to their personal image of the Universe. The rest can't seem to tell the difference between a reference book and something that might actually teach them something.
The "this book isn't necessary" chatter appears everytime
-- Slashdot: When Public Access TV Says "No"
Yes, but abstracting is such a minimal performance loss that there's no reason why it houldn't happen. In fact, if the DB was made common, we wouldn't need an abstraction layer on top of it. Since everything
;P
The problem with php, is if the application's require/include tree get's large, it has compilation problems at times. Granted, you may not see it easily, but I've seen it happen on files that just declare variables.
And my knowledge is based on C, C++, perl, java and php, so no need to get sarcastic
-
ping -f 255.255.255.255 # if only
Yes, but by not preventing people from making bad decisions is just as bad as promoting it. It's a bad mark on the language to allow bad things to occur. Look at c. buffer-over-flow city. If you knwo what you are doing, of course you'll win out, but you brin in a developer who doesn't think of the long term effects of gets() or the long term effects of using functions that are only usable with one db (switching db's becomes a pain), you lose.
-
ping -f 255.255.255.255 # if only
First off, we're not talking about PHP the language; the complaint was specifically against the API provided with the language.
.. this is not a problem subject to little one line programming slips .. youd have to be a pretty lousy programmer to use mysql_dothis, mysql_dothat and then get pissed off after 5 weeks of development that your code isn't portable to prosgres or whatnot.
That said, I really hope you're not comparing language weaknesses like making buffer over flow errors easy to commit and 'weaknesses' like letting the developer choose speed-vs-portability.
Good programmers still make little mistakes like off-by-one and buffer-overflow errors, and sure, you can say the language is asking for it in the case of C. But portability, when the api function names specifically refer to the database you are programming non-portably against is something the developer should be intrinsically aware about
You're almost saying that all hooks of an API should be horizontal, and never heirarchiel; and that it is the weakness of an API when the programmer uses non-portal code that is clearly named and documented as such (?!). Its a completely unreasonable and very inefficient approach; at the end of the day, the developer needs to have some accountability and responsibility for his use of the tools presented with him. Seeing as the PHP API makes it very obvious (as in right in the function names) which level of portibility you are programming to, I wouldn't hesitate for a moment to fire a programmer who accidentally wrote a PHP application using the mysql-specific calls when the requirements of the project included database portability. Wouldn't you?!
"Old man yells at systemd"
I wouldn't hesitate for a moment to fire a programmer who accidentally wrote a PHP application using the mysql-specific calls when the requirements of the project included database portability. Wouldn't you?!
:)
I would. Because it depends on the position of the programmer. Is he a junior programmer? If so, I wouldn't want to fire him since he may not have the knowledge to do any better. That's why a good language or api would support the programmer and not be a wasteland (severity not intended) of things you can do.
And just 'cause things are obvious to you, maynot be obvious to you.
-
ping -f 255.255.255.255 # if only
And I'll skip the sarcasm since you're familiar with the subject you're talking about :)
;) heh
Thank you my liege!
Agreed in some cases the difference might not be worth using the old way but there is still a need for it in some applications.
My argument is in MOST ways you'll not see much speed differece, and the bit you see in load you can throw one more server in the load balancer pool AND... (and...) what you lose in speed, you'll win back in development flexibility, wether it's changing DB's or developing new code. I'm sorry, having oci and oracle libs at the same time, and not deprecating one really.. bugs me.
-
ping -f 255.255.255.255 # if only
Oh hang on.. I forgot.. PHP is just a Perl ripoff that has even less features.
Continue with your code.
mogorific carpentry experiments
As a professional PHP developer, I've found Web Application Development with PHP 4.0 to be one of the best books I've ever purchased. The authors, Tobias Ratschiller and Till Gerken, don't spens time and paper reprinting the manual. instead, they discuss the abstract concepts that distinguish a well-written webapp from a poorly-written one.
Coding conventions, organizing libraries, API design, and programming in a team environment are all discussed in depth. They include case studies and real-life examples of the concepts they cover.
To summarize, if you want a great discussion of PHP development that you *can't* get from the online manual, check this one out.
Unless you know the future of everything you'll ever do, you will never know if something wont' come along.
You start with a specific idea but make things general enough that if you change certain variables it won't be the death of everything. DB's, db strucutre, template engines are major points for speed improvements. So if one DB is faster than another or another template engine is better, the work becomes less.
-
ping -f 255.255.255.255 # if only
MySQL has no concept of prepare_statement, what would you do in that case? The names of the functions are the actual names exposed by the underlying C client libraries. The Perl abstraction layer has to call these exact functions with their wierd names. Sure, it hides that from you. But that's just what PEAR::DB does.
:)
Right. PEAR::DB does a great job. Now hide the extra functions!
As for your mysql thing, you make prepare remmeber the statement you want to run, like a good abstraction layer normally does (that we've seen so far, like pear::db or perl's dbi).
-
ping -f 255.255.255.255 # if only
People always talk about how wonderful PHP's online documentation is. Its okay, and the section at the end with the gazillion functions is certainly comprehensive (and reminds me why PHP is not my first choice of programming environments).
However, I thought this book was *much* more intelligently organized. The section titles made sense. A was followed by B was followed by C. It spoke about good practice and design.
If this is what most people learned to program PHP with there whould be significantly less horrid PHP in the world. I think this is actually a return to the Oreilly golden era, away from poorly concieved fluff books like Essential Blogging.
Now if they could come up with a PHP (or Python, or Java) cookbook as good as the Perl cookbook, we would know that the good days were here again.
Before starting PHP I had actually done quite a bit of database programming using various languages including Perl. And I agree that database abstraction is useful in some cases, but as soon as your database needs go beyond trivial selects it all falls apart. Try switching from M$-SQL to Oracle halfway through a project. The fact that you used a database abstraction layer might save you 10 minutes of global search and replace on some db-specific function calls, but then you spend the next 3 weeks converting your schemas, stored procedures, triggers and the SQL itself. Try taking an Oracle query that includes DECODE() and make it work on some other database! A DB abstraction layer doesn't solve any of this.
(Well, some try to solve the schema issue by forcing you to describe it in some generic XML format, but you still need to get in there and get your hands dirty to make sure the different types each db supports are handled correctly)
When I write applications I write it with the databases I want it to run on in mind. I write database-specific functions to fetch data, update data, etc. I do this so I can use all the DB-specific performance tricks I can. And I will simply state that this application supports MySQL, PostgreSQL and Oracle, for example. If someone comes later on and tells me it needs to support another one, ok, then I add that support. For most dynamic web apps the bottleneck is the database. I am completely unwilling to trade performance for portability on that particular aspect. You don't trade away performance on the one critical factor in your architecture.
So, that is why database abstraction is not in the core of PHP and why PHP gives you access to all the intricacies of each database API. Others have layered abstraction layers on top of this low-level API support and that is fine, but PHP was originally designed as a tool for me to solve web problems and as such the design reflected my approach to web-database integration.
If every database conformed to standards and the SQL and schemas were portable, then yes, not using db abstraction would be asinine, but that is not the case, and it will never be the case as database vendors always want to distinguish their product from the next guy's.
PHP is used for more than your "small" MySQL-based website. Not only does it support a lot other databases beside MySQL,
but it scales very good too.
As for ASP, a good programming enviroment?
*laff*
[alk]
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
http://sourceforge.net/projects/scoop
Scoop is a weblog script written in Perl with a MySQL backend. It is different then other weblogs, in that it allows the users to decide what stories get posted.
Frankly, you're wrong. I've made $LARGENUM over the last six months migrating a few websites from legacy Interbase servers to newer Postgresql systems. The process was far more complex than it needed to be, especially since the SQL itself was very simple on each of the sites (no transactions, no views, nothing complicated). Why?
while ($foo = ibase_fetch_row($resultHandle)) {
but in Postgresql, you have to:
$max = pg_num_rows($resultHandle);
for ($i = 0; $i { $foo = pg_fetch_row($resultHandle, $i);
pg_query versus mysql_query. Note that while the functions are nearly identical, the order of the parameters is swapped. Who the $#!$@# thought that was a nifty idea?
In other words, it's pretty much impossible to swap out a project's backend once you've started.
No, I've relegated PHP to the "toy language" category. Can it be useful on occasion? Sure. Will I use it to whip up a comment submission form or similar lightweight interface? You bet. But there's no way, ever, that I'll even consider PHP for serious development work in the future.
Dewey, what part of this looks like authorities should be involved?
Like I said, if you have trivial SQL, use one of the umpteen db abstraction layers that are out there for PHP, or know beforehand that you might need to switch databases and think ahead a little bit.
The order of arguments and the way the functions are laid out for each database are that way because they reflect the underlying API. People who already know the underlying API for a specific database are in heaven when they hit the PHP API for the database as there is nothing new to learn. And even better, they can use the per-database API documentation directly and have it apply to PHP.
You keep arguing the exact same point. You want the native db function to be an abstraction layer whereas the core of PHP provides a direct API interface to each database and pushing abstraction layers up a level. As far as I am concerned that gives you the best of both worlds, but I guess you don't see it that way.
Here's the prototype for mysql_query from mysql.h:
Since the arguments to PHP's mysql_query are swapped when compared to the actual C headers, I'm curious: what "underlying API" does PHP agree with? It sure isn't MySQL's own C API.
Dewey, what part of this looks like authorities should be involved?
Well, in that particular case they are swapped because you can't put an optional argument before a required one. In most apps you only talk to one database at a time so always putting in the link identifier (which is the MYSQL *mysql part of the low-level API call) was a bit of a hassle, so it was made optional.
Still, the name of the function and the way it works mimics the lower-level API, but yes, here and there we toss in a few changes for convenience. You can call it maintaining the spirit of the low-level API if you will.
Yes, you'll save time, but you it'll be a little longer than 10 minutes.
First off, i have to learn a whole new set of DB function names since all of them have different names. Some functionality doesn't exist between the two db api's.. such as mysql and a prepare like statement. What if I switched from oracle to mysql? Now i have to restructure my code heavily. A prepare should remember what the query is and return a statement handler.
Secondly, most queries will stay the same. Most queries would be simple selects, insert's and deletes which are SQL (92?) compliant in the first place.
This is exactly the reason why php is not as enterprise level as say java. Even C++ has it's advantages, but it's all in the OO.
-
ping -f 255.255.255.255 # if only
But that's exactly my point. Why wasn't that also done for pg_query under the same rationale? The current situation has two almost identical functions with swapped parameters with no apparent good reason.
Dewey, what part of this looks like authorities should be involved?
Well, here we have only 1 optional arg and we can actually leave the order as is. With mysql_query() there are 2 so having the optional first is difficult.
But again, these are minor little things to change compared to converting schemas, stored procedures, triggers, etc. when you are moving from one database to another. At most you have to spend 10 minutes going through the prototypes for the 5 db-specific functions you used in your app.