|
I'll agree with you on this one.
|
|
|
|
|
Thanks for the input. I tend to be one of those people that will go with DB ref integrity when possible, because (in my experience) it's the best way of ensuring that true integrity exists - when there are too many devs on one project it just takes one lazy Friday afternoon for somethign to slip by. Yes, it can be caught in unit/qa/whatever, but controlling it at the DB is a great insurance policy.
On the other hand, we rarely, if ever, actually allow record deletion. And the second approach is definitely more flexible.
Thanks
|
|
|
|
|
Yeah, number two beats number one.
But what about taking it a step further and allowing for many-to-many association of notes to entities? Unless you invoke YAGNI, I could see the conceptual benefit of allowing multiple notes for an entity and associating one note with multiple entities. If you like, you could have a notes table for each table for which you want to associate notes; that would reduce the amount of table duplication. I wouldn't be concerned about the lack of referential integrity*; you could implement that programatically, or even have a cleanup routine to delete orphaned notes.
Another alternative is to have a notes field in each table that should support notes. That allows referential integrity, but only one note per entity -- unless you chain notes together.
* I've said it before and I'll say it again... I once worked at a place where referential integrity wasn't allowed in production databases -- once the applications were tested, it wasn't needed and it "bogged down the database"**. 
** Rdb on OpenVMS.
|
|
|
|
|
Hi - thanks for the input.
Truthfully our design already allows for a many-to-many - I just didn't include that detail here because I was trying to keep the explanation less "muddy". Our intent is to allow one or many notes to relate to one or many (and any combination of) customers, quotes, work orders, products, etc. The potential power of knowledge-base access based on this approach is great - the real question is going to be creating a UI that encourages the users to easily select the related criteria and/or BL that automatically selects the appropriate matching related items.
For ref integrity, one thing I forgot to mention is that we rarely ever allow record deletion through most of our objects so it should be even easier to control that programmatically.
I'd prefer to steer away from the one Notes field per table - that limits us to a very 80's approach and hardly moves us forward.
I admittedly do not invoke YAGNI enough, but in this case our immediate need for multiple fields already justifies the above approach; knowing that this will likely be expanded just adds yet another argument to the approach.
As for the approach of ref integrity not being allowed in production dbs... well I've personally seen the mess that can create. While that mess may certainly be related to holes in another processes (dev, testing, qa, etc.) I still don't expect to ever implement that type of policy. It's one thing to have orphaned records in a communication log, quite another to have an orphaned inventory audit trail!
Thanks so much for the reply.
Cheers,
Chris
|
|
|
|
|
G-Tek wrote: we rarely ever allow record deletion
Very wise.
G-Tek wrote: It's one thing to have orphaned records in a communication log, quite another to have an orphaned inventory audit trail!
Their point was that that would be detected by referential integrity in test. It's another reason not to use stored procedures. 
They also wouldn't allow me to create functions -- "Too much metadata! You're bogging down the database!" So I created them programatically when I needed them and dropped them when I was done.  Then they they laid me off or some reason. ::shrug::
|
|
|
|
|
Not allowing record deletions does save a lot of headaches. The reality is that in most cases it really isn't necessary. The biggest issue that we have is typically during training where dummy records get created that they don't want to see - we can, of course, delete those behind the scenes, but it still raises the question of why they don't see a delete button.
So then for some entities we have created a deleted status/flag/bit. That way the user "believes" the record is gone, but we can still magically retrieve it if necessary - or give access to high level users to access the "deleted" records.
Of course, for things like communication logs... they're logs! They shouldn't be deleted, only archived.
PIEBALDconsult wrote: They also wouldn't allow me to create functions -- "Too much metadata! You're bogging down the database!" So I created them programatically when I needed them and dropped them when I was done. Then they they laid me off or some reason. ::shrug::
I have changed my approaches over the years and have worked with people with very different approaches - from those that wanted to push all the BL to the stored procedures, to those that want to wipe out stored procedures and put everything in code. It's too bad that there is rarely a 100% right and pure answer to the scenarios we face!
|
|
|
|
|
G-Tek wrote: deleted status/flag/bit
Right. If you give them delete, they'll want undelete. 
|
|
|
|
|
hi.. everybody..
i'm using ssrs2008 without IIS ...
i've created my reports and deployed in my system.. i.e
http://localhost:8080/rpt which are working fine.. (" i.e in XP prof SP3")
now i've developed an application in different system which windows server2008
in that i'm using reportviewer now.. what i want is when i run the project in
windows server the reports display from my system.. i.e my url http://myip:8080/rpt
error msg("enable to connect remotely")
please help me...
i've tried by giving my http://myip:8080/rpt in another system .. but
it will ask username and password i've tried giving my system and password .. and also the system name and passward where i'm trying to execute.. the error is displayed
("An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.")
wat to do...
modified on Saturday, December 4, 2010 8:25 AM
|
|
|
|
|
You need to design your report as a LOCAL report rather than a published report. That means your app gets the data and delivers it to the report, the report has a RDLC extension and has no awareness of the data connection.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
hi.. everybody
i got the solution here..
http://community.discountasp.net/showthread.php?t=4402
but now again i'm in a problem
how to assign security role for different system in a network
for a folder or it can be report..
i want to assign diferent permission for different users..
|
|
|
|
|
Dear All,
Forgive me for asking what must seem to most like an obvious question, but I am a SQL server newbie.
I am using SQL Server 2005 and I have a certain field which contains both a city and a state in one file; i.e., Portland, Oregon will be listed as
CityAndState
------------
PORTLAND OR
Notice that this is a single VARCHAR column and there are a whole bunch of extra spaces in between the 'PORTLAND' and 'OR'.
How do I get it so I have
CityAndState
------------
PORTLAND OR
<pre>
<div class="signature">Sincerely Yours,
Brian Hart
</div>
|
|
|
|
|
you could do a search for double space, then replace double space by single space, and repeat until nothing gets found.
a possible improvement would look for 8 spaces and replace them by 1; then 4 by 1; then 2 by 1.
However, it is simply wrong to store two pieces of data in a single field, you really should split them permanently and hence avoid all future formatting issues.
|
|
|
|
|
I could say 'That is horrible', but I won't. Ooops, just did it.
|
|
|
|
|
Use the REPLACE function. Check here.
|
|
|
|
|
I would be intrigued to know why this answer (above) has been down-voted so much. I think it links to a good solution.
|
|
|
|
|
Turn it into two columns and then you can format it however you want
DECLARE @city varchar(20)
Set @city= 'Portland OR'
select
SUBSTRING(@city, 1,CHARINDEX(' ', @city)) as [city],
REVERSE((SUBSTRING(REVERSE(@city),1,CHARINDEX(' ', REVERSE(@city))))) as [state]
This assumes no trailing spaces after OR. If there are add some TRIM() in there.
|
|
|
|
|
SELECT REPLACE(CityAndState,' ','');
Code just replaces DualSpace with NoSpace.
Regards,
Hiren.
"The more we give of anything, the more we shall get back." - Grace Speare
(you can consider this quote while giving vote also)
Microsoft Dynamics CRM
|
|
|
|
|
This is no good if there are an even number of spaces between words.
|
|
|
|
|
i am unable to start the SQL Full Text Search Service from SQL Server Configuration Manager previously i successfully started the service and extracted the data from my table but after restarting the system there is an issue sarting this service
following windows msg appears:
"the request failed or the service did not respond in timely fashon. Consult the event log or other applicable error logs for details"
|
|
|
|
|
What does it say in the event log?
|
|
|
|
|
I created a set of tables in which the primary keys are set to uniqueidentifiers with a default value of newid(), which is the function that generate new guids in Transact-SQL. While I can create a uniqueidentifier variable and initialize it before inserting a row, that would obviate the reason for creating a default value in the first place.
But unlike an identity field, there is no function, that I can think of that would retrieve the most recently created uniqueidentifier. I would like to use this value within the body of a stored procedure but I can't think of any way to get it short of creating it ahead of time and not using the default value mechanism.
I could access the new value in a trigger, but then how would I pass that back to the stored procedure? I don't think that a trigger is the way to do this, but I don't know.
Can anyone show me a way to do this?
|
|
|
|
|
I hate GIUDs
I do not use the default value, instead I create the GUID (in the stored proc) before inserting and therefore already have it for the return select or an out parameter.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I am rather fond of GUIDs.
They are so much better than lowly ints. I can create a hierarchy of various rows and insert them all in one swell foop, rather than doing one, getting its ID, passing that to the next... 
I do set the default value, as you did, but that merely gives me flexibility -- in some cases I may not need to know the ID, in others I may; so I can either set it myself or let it default, depending on need. If you don't want to use the default value, don't set it, big fat hairy deal.
Autoincrement fields are a nasty kludge that never should have been implemented -- as I recall, in Oracle we used "sequences" which allowed us to get the "next value" much like we can get a new GUID. When the company I worked for started to shift from Oracle to SQL Server, we implemented our own sequences, we never used autoincrement fields -- I still never have.
|
|
|
|
|
So, I have one person that hates GUIDS and one that likes them.
I chose them for the absolute certainty that there would be no collisions in IDs between tables and / or systems. My main goal was that I wanted to uniquely identify any object in my application. I won't have that many objects that I could not have used integers, but with integers to do that amoung many tables I would have to devise some sort of function that always delivered a new unique one when creating a row in any table.
If I could build a suitable function I still might do that. I probably could do so by using a single row table with one tuple holding the last integer used, but I have not tried that yet.
One thing I don't understand is why Microsoft created unsigned integers in all its programing languages, but did not provide the same feature in SQL server. I really do not want to use negative values, but the fact that there is no unsigned integer cuts my value pool in half if I choose to start with zero.
I also had some Oracle experience and I think I remember the sequence object. I don't know why Microsoft didn't implement something similar. For my part I would like to see sequences that deliver either unique unsigned integers or unique unsigned doubles. That would handle virtually any system that I can think of as a means of generating unique keys
I have been taught that SQL Server is much faster when dealing with integer keys because it uses integer arithmatic in its underlying calculations. Is this correct? And if so, how much faster would it be?
For now, I have chosen to create the IDs before inserting the rows so I already have them for other purposes. I have tables that serve as links for many to many relationships and that is where I am using the IDs.
My next challenge is to figure out how to maintain data for directed acyclic graphs, the idea of being able to show the relationships between any object in the system to any other object in the system even if that realtionship is a remote relationship like a grandparent of a cousin object, etc. I have found one article on Code project regarding that task, but I am looking for more to see if there are other ways to do this and so that I can understand the process better.
|
|
|
|
|
henry1951 wrote: If I could build a suitable function I still might do that. I probably could do so by using a single row table with one tuple holding the last integer used, but I have not tried that yet.
I think what we* did was create a multi-row table that supported multiple "sequences" -- the app could request the next value for the User sequence, or the Transaction sequence, etc. It also had fields for Min and Max -- if the sequence reached the Max it would wrap around to the Min (I assume that there was a need for that in one of the apps).
* Not that I was involved in that effort at the early stages. Wish I had been -- the idiots put data access in the UI layer  .
henry1951 wrote: unsigned integers
Yeah.
henry1951 wrote: faster when dealing with integer
Well, they're smaller, quicker to compare. But I don't consider that to be a reason to select them over GUIDs -- just don't use strings as keys .
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
