|
Pete O'Hanlon wrote: it is up to your application to ensure integrity
Yeah, on a previous job (using RDB on OpenVMS) we had referential integrity on the dev systems only; the code was expected to be correct and fully-tested before it was deployed to production, so the database needn't check.
They also said that metadata slows down the database, so I wasn't allowed to create functions in the database.
Now that I get to use SQL Server, I do set up referential integrity... but turning on cascaded deletes still feels like cheating.
|
|
|
|
|
PIEBALDconsult wrote: but turning on cascaded deletes still feels like cheating
It feels dirty - so dirty. And it's one of the reasons we don't do deletes - we use statuses to control whether a record is visible or not (and that way we don't worry about accidentally deleting something important).
|
|
|
|
|
Pete O'Hanlon wrote: don't do deletes
I agree with that.
|
|
|
|
|
In my line of work speed is not such an issue as robustness and solution being as error proof as possible. So I think database and application which uses it must both be able to gracefully handle whatever crap is thrown at them (i.e. checks on both sides).
That works for me and is my opinion based on experiences so far. Of course I'm always opened to well argumented ideas.
modified 19-Nov-18 21:01pm.
|
|
|
|
|
Pete O'Hanlon wrote: DBA
Dumb bloody A$$@#$!@'s 
|
|
|
|
|
More along the lines of "does b*gger all".
|
|
|
|
|
True also 
|
|
|
|
|
Philip Laureano wrote: Is it a horror, or not? And if it isn't a horror, why would you say it isn't?
Are you the person that has to clean up the data once it is a mess? The answer to this question is the same as to your one above...
|
|
|
|
|
Philip Laureano wrote: Is it a horror, or not?
Yes, it is.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Philip Laureano wrote: and not even the upper management knew about it.
As if they know what is under the code 
I've to come across upper management who know what goes on in the code. Of course there some, but those are exceptions
try<br />
{<br />
<br />
}<br />
catch (UpperManagmentException ex)<br />
{<br />
<br />
}
/* I can C */
// or !C
Yusuf
|
|
|
|
|
Compile Time Error #OMGWTF error UpperManagmentException can never be caught.
Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop.
-- Matthew Faithfull
|
|
|
|
|
dan neely wrote: can never be caught
Even when they do get caught they get big bonuses. (boni?) 
|
|
|
|
|
I believe it is. You're leaving data integrity up to the USERS! Are you kidding me!? 
Data integrity is everything. You can always index and perform other optimizations if you want to speed things up, even throw hardware at it if necessary, but fixing corrupted data is a nightmare with no easy solution. Given the horsepower of modern systems, there's no excuse for not using this important feature.
|
|
|
|
|
A few years ago worked on an open source php application that implemented its own object model of the database.
All the relationships (and types) were defined in each extension of the base and that worked quite well in making easy coding (only used code in base class with data from the actual objects themselves - well, only things defined in objects were structure, relationships and some name formatting). But to let the end user do all the deletes/updates by hand, hahaha.
|
|
|
|
|
Horror!
Robust code = belt + braces
Poor code = sticky tape + string
Horror = expected to hold up own trousers 
|
|
|
|
|
In my mind, it's simple.
Each tier should take care of itself. The database should take care of ensuring data integrity. Beyond that, all business rules belong in the middle tier.
Data integrity should also be enforced at the middle tier level, but there's no excuse for the database not taking care of itself. You cannot ensure that all applications accessing the database will enforce the rules (ever hear of SQL Server Management Console, TOAD, et. al.?); therefore it's up to the database to protect itself.
Even when using IsDeleted flags instead of true deletes, you can enforce a certain amount of consistency using stored procedures, triggers, etc.
|
|
|
|
|
We Can maintain integrity from Front End tool, but it is better to use Relations between tables, in some cases we need to make database flexible. so don't under astimate your seniors.
Best Regards,
Chetan Patel
|
|
|
|
|
Recently I was going through a code written by one of the developer. I just got startled by the way a user message confirmation page was named and the message was being passed to it.
It was a little user information page named as 'ErrorDisplay.aspx' and he is passing message to it like ?lErrorMessage=Data has been updated successfully&sErrorIdentificationNumber=4232343523&ErrorDateTime=
I was just curious and tryed to enter a alert('Dog') and it immediately pounced back to a 'Potentially Dangerous Page...' from .NET Framework.
At the glance, I could guess the following are the horrors in this part of the code:
1) Wrong nomenclature to the file
2) Too big variable names. After all, QueryString is limited right? The developer is not expectant of any appraisal from the user.
3) Cross Site Scripting vulnerability
4) Bad and inconsistent variable naming.
When I was thinking over this, a few days back, we had a discussion in a technical forum regarding dependency of Exceptions for normal application flow, which is really a strain on the server besides the pathetically poor programming practice.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Dear all
I need to know whether printer support "Job Retention" (Job Storage) feature or not, ie whether printer can store the jobs so that they can be printer later by issuing a password to printer control panel. (Different options for job storage are "Hold and proof", "Private Job", "Quick copy" etc.
To know all these information I tried WMI in windows, various vc++ printer capabilities APIs without any luck.
Is there some way so that I can get all these information.
please help..
Regards
Shobhit Jain
|
|
|
|
|
Member 2734270 wrote: Is there some way so that I can get all these information.
Yes. Posting it in the correct forum will surely help.
He died when he was alive.
|
|
|
|
|
This forum is for discussing coding horrors you have run across, not for programming help...
"That's the problem with a spell checker. It only helps with bad spelling, not stupidity." - Rob Graham
|
|
|
|
|
I can see how this might turn into a horror story if you have personel or classified information on a printer and the printer was stolen or accessed by someone not authorized.
Most printers have a diagnostic capability, that is they can be put in diagnostic mode. Setting may also be accessable if printer has a setup/configuration menu option. If printer has LCD you can scroll through settings looking for anything about auto memory purge, store jobs, batch storage, and disable the appropriate setting.
You can also search online for printer model to see if printer has this capability.
MrPlankton
|
|
|
|
|
The member ###### strike again!
ROFLOLMFAO
|
|
|
|
|
Is this about retaining your job using capabilities of printer?
"Legacy code" often differs from its suggested alternative by actually working and scaling.
—Bjarne Stroustrup
|
|
|
|
|
Member 2734270 wrote: Is there some way so that I can get all these information.
No
Member 2734270 wrote: please help..
No
There is no Ctrl button on Chuck Norris's computer. Chuck Norris is always in control
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
