Hello

According to Wikipedia's PHP page, PHP "is a general-purpose scripting language". Does that include being suitable for duplicate files detection?

More specifically, the task is collating files from workstation backups into a single place, preserving directory paths and replacing duplicates with hard links. This will be a regular task on a lot of files so performance is important; our current proof-of-concept solution uses a PostgreSQL database of file "fingerprints" to speed duplicate detection. Does PHP have PostgreSQL integration?

I am asking these questions as a follow-up on an earlier thread asking for programming language recommendations for this task. Since then I have learned that PHP skills are available locally.

Best

Charles

Hi -

A: It wouldn't necessarily be my *first* choice. But sure - why not?

A: Absolutely yes

A: There's the rub. I can't think of any reason PHP *wouldn't* peform as well as any other scripting language.

SUGGESTION:
Write some "stress tests" and see if PHP holds up:

a) Capacity: Will it handle needed #/records at a time?
b) Speed: Will it complete needed #/records in a specific time period?
c) Etc

'Hope that helps

PS:
In your "other thread", you mentioned Ruby. Once you've run your "stress tests", it would be instructive to port them to Ruby and compare the results (Ruby vs. PHP).

Please post back what you find - we'd definitely be interested

2 members found this post helpful.

Personally, no.
Widely used amongst newbies. More security holes have been created through PHP than perl or anything else, IMHO.
Learn a real language or use perl.

0 members found this post helpful.

You ventured into "holy war" territory :}

As others already pointed out - PHP can be used for it, it does
have a PostgreSQL interface, but so does pretty much any other
scripting or compiled language.

For computationally intense tasks, or work w/ linux file-systems
using a Web language wouldn't be the first choice, either. I'd
go perl, or, if high speed is of more concern than development
time, C instead of PHP.


Just my tuppence.


Cheers,
Tink

1 members found this post helpful.

Hi -

Tinkster and I are in complete agreement.

I definitely want to emphasize, however: if you have PHP expertise readily available, then by all means at least *TRY* PHP. There's absolutely no reason NOT to use it, as long as it meets your performance requirements.

And the only way to verify that - with PHP, or with any other language - is to TRY it.

And please ignore Smoker's comments - he's either seriously misinformed, he woke up on the wrong side of the bed (or perhaps both). One can cast aspersions at any web language they want. Sometimes, it's justified (like IIS and ASP 3.0, for example ). But in MOST cases, MOST contemporary web languages share MOST of the same benefits and drawbacks. There is no "black" or "white". PHP is perfectly appropriate for many projects. And it's the foundation for many of the most successful projects in the world today.

IMHO .. PSM

PS:
Important comment: keep your eyes wide open for ANY application and ANY SQL script that faces the Internet. You can't be too paranoid for ANY language or framework you choose to use.

2 members found this post helpful.

Thanks all for replies

While PHP skills are available locally -- and that is relevant when choosing a solution language -- a solution is seen as urgent and a) I don't know how immediately available the PHP people are for a new development, b) I'm progressing OK with Ruby and c) I would have to start over learning PHP.

So, and partly in response to paulsm4's request for performance comparisons, I'll continue developing in Ruby and ask the PHP people to use it as a functional specification for a PHP equivalent.

@Tinkster: thanks for suggesting perl or C. Enquiries about local programming skills have so far only produced a suggestion for PHP. In case someone has to learn enough about a language they don't know to do maintenance work on the solution, Ruby would be easier than perl and maybe than C. Given that I am the only resource available for the initial solution it is also relevant that perl does not attract me and my C, once fluent, is very rusty.

Regards security, the solution will run locally.

Best

Charles

Ok.

Apart from paulsm4's comments they have mostly been constructive.

But :

PHP

Hypertext preprocessor.

What does that tell you ?
Perhaps this scripting language is best used for displaying db information on a web page ?
Given the experience of 15 years on the web, (and writing stuff pretty much for that whole time) PHP is not the language to use for doing critical filebased and database operations.

Do you remember PHP-Nuke ? How did that get on ? Do you really think that all the problems with the language are "sorted out" ?

Regarding the availability of skills - of course there are people with the skills, very little skill is needed with PHP, unless of course you want your database contents to remain confined to your own organisation !

Do not use a language designed to be web facing for mission critical tasks. You will regret it.
I have lost count of the number of supposedly "modern" systems that use PHP and require you to "turn off" safe_mode. Which gives PHP the run of your system !

Yes it's your decision, yes you CAN use PHP. But don't ask for opinions then complain if they don't fit the answer you wanted. And buyer beware as always.

I thought you had more sense Charles.

Thanks smoker

I know nothing about PHP apart from being vaguely aware that it is used for web applications. That's why I asked the question. Knowing nothing, it is difficult to form an opinion when given conflicting advice, especially when that advice is given by knowledgeable, respectable LQ members and the local PHP programmers. It would be great if the members who know about these things could debate their differences in this thread (without it descending into a "holy war"!).

FWIW I suspect Ruby, being designed for this sort of work, would be a better solution than PHP which has grown into these areas. If nothing else, there will be a lot more resources on the 'net about using Ruby for this sort of work than for PHP.

Given that the solution will run locally with no network component, security is less of a concern than other factors.

Closure: the project is effectively completed and working satisfactorily using 3755 lines of Ruby with some bash to link it all together. It seems unlikely that the PHP-sperts will be interested in coding the same just for comparison purposes.