|
Hi again Luc Pattyn
From a quick glance at what you have just put there that might actually do it 
Your patience has been amazing and I wish to say a big thank to you for that.
I am sorry if I have caused you lots of stress in trying to figure this, I know I could probably explain things better and of cause it would be eaiser to maybe have let you come and look at the site and pages which has only crossed my mind.
Am going to try what you put forward and see what happens
Many many thanks.
Kind regards
Ray
|
|
|
|
|
Hi Ray,
it was a pleasure helping you out.
My database experience is young and limited (I'm more a reader than a writer in this forum), however at the start this looked like a challenge I might just be able to cope with and certainly would learn from. And I tend to like potential win-wins.
See you.
|
|
|
|
|
I'm hoping someone can shed some light.
I need to create a database with Employees, Clients, and Practitioners. An employee could be a client and a practitioner could also be a client. I am hoping to design the database in a way that I only have to maintain name, demographic information, phone numbers, and emails once vs. having to change an address in multiple tables. I thought about having an entity table with the names, email table, phone table, address table, and then a table for each specific information such as a client table, emp table, and practioner table.
Any thoughts on what the tables should look like to accomdate or is it better to have the users maintain the information multiple times.
Any constructive feedback is appreciated.
digicd1
|
|
|
|
|
You could create a generic table that contains people, and then Employee, Client, and Practitioner tables that have a "personID" and then the unique information for each.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
digicd1 wrote: I am hoping to design the database in a way that I only have to maintain name, demographic information, phone numbers, and emails once vs. having to change an address in multiple tables.
So, you're absolutely sure that every practitioner uses the same phone-number if they become clients? No practitioner who separates their workphone from their private phone?
digicd1 wrote: I thought about having an entity table with the names, email table, phone table, address table, and then a table for each specific information such as a client table, emp table, and practioner table.
That would lead to a whole lot of joins to get a single record. How about a table for People, one for Clients, one for Practitioners and one for Employees?
digicd1 wrote: Any thoughts on what the tables should look like to accomdate or is it better to have the users maintain the information multiple times.
Normalize the model. This time, there's no viable alternative that I can come up with
I are Troll 
|
|
|
|
|
I agree, that is alot of tables and it would only be the beginning. If a practitioner was a client then I would probably have two addresses. Once for work as a practitioner and one for his home as a client. If an employee was a client, I would have a home/work address for this individual as an employee and a home address as a client. Since the home address repeats itself - I could minimize duplicate records by having an address table vs. having the user be responsible to change the home address in two different locations. Do you think the extra table and joins would be a huge performance impact and would be better to store twice?
|
|
|
|
|
digicd1 wrote: Since the home address repeats itself - I could minimize duplicate records by having an address table
He'd still be a client once, and a practitioner once. You'd need a link to both addresses. The address might be registered and linked to more than once. That'll make complicated queries, and I doubt that you'll save a lot of room.
It's a form of premature optimization, don't do it.
digicd1 wrote: having the user be responsible to change the home address in two different locations
If it's two different entities, then they shouldn't be changed simultanously. Likewise, you could add a boolean to the Employee to let him/her indicate that their address as a client is the same address as their Employee-address. Depending on the boolean, you update either one, or both addresses.
digicd1 wrote: Do you think the extra table and joins would be a huge performance impact and would be better to store twice?
I think that storage-space is cheaper than cpu-time. You should really dive into normalization, three guidelines would help you get a relational model that you can build on. Once you have that, it's easier to spot where you can optimize things.
I are Troll 
|
|
|
|
|
Eddy,
Thank you for your reply. I think this answers my question. In summary it appears that using a database that is too normalized would really affect cpu time. And in an age where disk is cheaper, it would be better to have some information duplicated vs. slowing the entire system down.
Chad
|
|
|
|
|
digicd1 wrote: Thank you for your reply
My pleasure, I hope you don't mind me rambling on about the importance of normalizing too much. It may eat away a bit of your time, but it's well worth the investment.
digicd1 wrote: In summary it appears that using a database that is too normalized would really affect cpu time.
A database can't be "too" normalized. A "good" level of normalization would be BCNF[^]. That should give you a correct model, without (much) redundancy. Keep in mind that most RDBMS-es are optimized to work with relational data, in a relational format.
digicd1 wrote: it would be better to have some information duplicated vs. slowing the entire system down
That sounds like a statement on optimization again 
I are Troll 
|
|
|
|
|
Tables
People
Address
PeopleType
lnkPeopleType - many to many link between people and type (client can also pe a practitioner)
AddressType attribute on address (you may want multiple links if you need to have the same address for 2 types)
This is a heavily normalised structure and is a pain to use so create a view based on the PeopleType.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
In SQL Server, I was doing this in the stored procedure:
param_record_id int OUTPUT
then I :
set param_record_id = scope_identity()
how can id o the same in mySQL stored procedure?
|
|
|
|
|
jrahma wrote: how can id o the same in mySQL stored procedure?
select sequence_name_goes_here.currval
from dual;
There's an example both on using sequences and returning values in the manual over here[^]
I are Troll
|
|
|
|
|
With SQL server, it is easy to have multiple select statements in a stored procedure, the outputs for the select statements are just tables in the output data set. Is it possible to do this in Oracle?
Thanks.
|
|
|
|
|
Yes. Have a look at this[^] thread to get some ideas.
|
|
|
|
|
I looked at the link you provided: It is not the same thing. The solution provided requires two select statements to return the same number of columns and the column types have to match. While in SQL server, you can have an arbitrary number of select statements and arbitrary data types.
I guess the answer to my question is NO. Thanks.
|
|
|
|
|
Here's[^] an example, scroll down to "Returning Results with Oracle REF CURSORs"
The example is for a DataReader, but the same principle applies to a DataAdapter.
"When did ignorance become a point of view" - Dilbert
|
|
|
|
|
That looks like a good solution. Thanks.
|
|
|
|
|
You're welcome.
"When did ignorance become a point of view" - Dilbert
|
|
|
|
|
i have configure the mail in sql server but when i am sending mail from sql server it is showing mail queue message but i am not getting the mail. i also grant the permission to msdb.dbo.sp_send_dbmail sp for public.
my mail sending code as follows.
EXEC msdb.dbo.sp_send_dbmail @recipients='test@bba-reman.com',
@subject = 'test',
@body = 'Test',
@body_format = 'HTML';
i just do not understand why i am not getting mail where as i am getting mail queue message when sending.
please guide me.
tbhattacharjee
|
|
|
|
|
Are you sure your smtp works as expected and not blocked from the subnet you trying to send the email?
You need dbMailUser permission for the id that trying to send email under msdb as well.
Please confirm.
Thank you.
Amit...
|
|
|
|
|
which version of SQL server are you using?
As barmey as a sack of badgers
Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
|
|
|
|
|
hi,
I am using SQL Server 2005 database.
I stored Thumb Image on two tables to the Image data type field.
When I compare these two images from both table is gives error...
"The data types image and image are incompatible in the equal to operator"
Statement :
"Select FP1 From E_CH16APPLICANTS Where FP1 In (Select Photo From Tmp)"
I just like to verify that this Thumb Image is exist or not...
by using SQL Statement...
Pls help me...
|
|
|
|
|
check for NULL or DBNULL, or use IsNull; or something like that. No need to actually compare anything if I understood your question correctly.
|
|
|
|
|
Exactly I want to know...
Can I Compare two Images stored in the Table...?????
|
|
|
|
|
I'm no database expert at all, however I've never seen SQL code that compares big fields (blobs, images), and I expect that whenever you (think you) need it, you have a bad design to start with; there should be no doubt that the image, when present, is the right one (the only doubt I would allow for is whether the image is present at all); and IMO it would most always be wise to have a separate field that uniquely identifies the image (a hash or CRC would probably be fine).
The only way I know to compare two blobs/images is by using a programming language (say C#), fetch the two blobs and compare their elements in a loop.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
