The Old Joel on Software Forum: Part 4 (of 5) - PeopleSoft sucks. What else is there?

PeopleSoft sucks. What else is there?

I work "with" PeopleSoft alot in my current job -- mainly providing interfaces that sane people can make use of. It's a horribly designed piece of crap.

The don't use NULL fields in the database. Numeric fields use 0 instead of NULL. Character fields use a single space instead of NULL. Aside from the difficulty of basing calculations on any number where 0 may mean 0 or it may mean NULL, this also means that you can't add any columns to any existing tables or all existing apps that insert into that table will fail. So in order to add another column to a table, you end up either using an "unused" column for the purpose or you have to create an entirely new table with one column for the not-quite-primary-key and one for the new data you actually care about. Since some tables are effective-dated, this leads to lots of difficult situations.

They don't use referential integrity *and* they duplicate data all over the place in the database.

Their UI is like something out of Windows 1.0 days.

Unfortunately, I hear SAP and OracleFinancials are equally pitiful in their own ways.

Are there any good, well-designed solutions? Would a company be better off writing their own from scratch?

Richard P
Friday, February 6, 2004

What do you PS for? Handling HR?

FredF
Friday, February 6, 2004

the funny thing is, peoplesoft is worlds better than oracle

The Artist Formerly Known as Prince
Friday, February 6, 2004

Where I work, PeopleSoft is replacing Chordiant.

Chordiant - it will do anything you want - you just have to write the code!

Name changed to protect the innocent
Friday, February 6, 2004

"Are there any good, well-designed solutions? "

No. As someone who has worked with huge enterprise systems for too long, all I can say is that the only position worth having in the enterprise software market is in SALES.

Friday, February 6, 2004

"Chordiant - it will do anything you want - you just have to write the code!"

LOL

amused
Friday, February 6, 2004

"it will do anything you want - you just have to write the code!"

I've got some software like that, it is called "Visual C++".

Software Engineer
Friday, February 6, 2004

Some of your comments are correct. Some entirely wrong.

<<The don't use NULL fields in the database. Numeric fields use 0 instead of NULL. Character fields use a single space instead of NULL. >>

Have you worked with a ERP which has NULL's. Its a nightmare to work with. For example,
SELECT 1+NULL from Dual returns NULL in Oracle.

NULL means "I do not know what is stored here". If you have NULL's in your database, aritthmetic operations may return NULL, GROUP BY operators work havc. You simply dont know what to expect.

<<No ReferentialIntegrity>>
Not very unusual for ERP's which work across databases. Let me give an example, If Peoplesoft works with 5 different databases like Oracle, SqlServer etc, instead of making sure the database handles referential integrity, the application handles it. Makes things much much easier.
But you are wrong in that Peoplesoft does not have it. Dig a bit deeper and you will find that there will be some internal tables which store links. They duplicate the sysstem tables.

Believe me. I have worked with ERP (not peoplesoft). If you have different code for different databases, maintenance is a nightmare. We once had written some stored procedures. What a nightmare it was to port to differnt databases.

Oracle Applications have referential integrity simply because they work only with the Oracle database. Oracle'; task is simpler.

Karthik
Friday, February 6, 2004

No need to enforce RI in the database if it's
happening in the application. Duplication
is bad though. Is there a good solution to the null
issue?

son of parnas
Friday, February 6, 2004

To work around the NULL problem you could define non 0 default values - I've seen "the end of time (31-DEC-2099), all 9s (9999999999), and the " " value for null strings. By defining default values you'll never encounter in real data you can avoid having the problem of dual meanings.

Lou
Friday, February 6, 2004

"No need to enforce RI in the database if it's
happening in the application"

Bwahahahahahhahahahahaahhahahahahaah

Ahhh.... someone who's never actually had an application with a backend database in production.

Philo

Philo
Saturday, February 7, 2004

Richard --

Stick around. PeopleSoft now are going to use DataStage instead of Informatica for their engine.

DataStage have a very distinct NULL field -- in fact, it is as anal as Oracle's NULL, as in you MUST view it as a third condition, as in 'true/false/Null'.

As for the ERP poster -- NULL is _GOOD_ not bad. How else can you determine valid number of rows? How else can you determine valid records? "Oh, this person was fired last week, but all of this week is 0, so that person must be still working.... righhhhht?" Aggregation? Sum? Average? Hello?!

Anyway, Peoplesoft will still support the Informatica engine, so you will have to explicitly upgrade. DataStage 7.1 will be the engine used and it is releasing very soon now.

T.J.
Saturday, February 7, 2004

P.S. DataStage is from Ascential.

http://www.ebizq.net/news/3627.html

P.P.S. No I do not work for them (at least not yet.)

T.J.
Saturday, February 7, 2004

NULLS have a very specific meaning - usually not applicable, missing or empty. If you have any kind of experience with databases you will learn how to deal with them.

Inserting "magic" or special values in place of missing or non-applicable data usually causes problems.

DJ
Sunday, February 8, 2004

"Inserting magic or special values in place of missing or non-applicable data usually causes problems."

It's entirely dependent on your data model.

For example, with a traditional star-schema dimensional model, NULLs are not allowed in the fact tables, and NULLs are very, VERY strongly discouraged anywhere in the dimension tables. And in point of fact, the lack of NULLs actually makes this model very functional for the things it was designed for (ad-hoc reporting).

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, February 8, 2004

"No need to enforce RI in the database if it's
happening in the application"

I have to echo Philo's point.
Bwahahahahahhahahahahaahhahahahahaah

The idea that the database and _the_ application are one is a source of many problems. The first one is assuming there will forever and a day only be one app using the data. One day somebody else will write another application that also uses the same data. Maybe a manager asks a junior programmer to knock him up a quick program to view some data in a certain way. This second app eventually grows like topsy, and it may end up either not enforcing the RI, or enforcing a different RI (misunderstandings easily lead to this sort of thing). Result: rubbish in your database. Always enforce RI at the DB level.

Breandán Dalton
Tuesday, February 10, 2004

You guys are a bunch of fat geeks.

Eat Me
Thursday, March 18, 2004