|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Saturday, December 29, 2012 1:58 AM
Points: 5,
Visits: 8
|
|
I know features of object orientation could not implemented, but i want to find a way to implement them. For example for implementing inheritance we can use foreign key. Please help me to find some ways for encapsulation and other features.
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: Yesterday @ 1:17 PM
Points: 8,641,
Visits: 8,273
|
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Yesterday @ 4:11 PM
Points: 37,741,
Visits: 30,020
|
|
tz.bahrami (12/26/2012) I know features of object orientation could not implemented, but i want to find a way to implement them.
Only advice I can give you there is don't. SQL is not an object database. You may be able to force some object stuff into the DB if you hammer hard enough, doesn't make it a good idea.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 9:31 AM
Points: 65,
Visits: 443
|
|
| Only expose stored procedures as the interface to the front end. Do whatever you like behind the scenes. It is about as object oriented as you can get with a database.
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 8:27 PM
Points: 6,735,
Visits: 11,788
|
|
Here is some available reading on the topic that may help you gain a deeper understanding of what things to consider before implementing your database:
Object-relational impedance mismatch, From Wikipedia
__________________________________________________________________________________________________ There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Believe you can and you're halfway there. --Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Saturday, December 29, 2012 1:58 AM
Points: 5,
Visits: 8
|
|
| In inheritance a child table can gain father's features, so if i add child table's primary key to father's table as foreign key, it can gain father's features it is like inheritance.is'nt it?
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 9:31 AM
Points: 65,
Visits: 443
|
|
tz.bahrami (12/27/2012) In inheritance a child table can gain father's features, so if i add child table's primary key to father's table as foreign key, it can gain father's features it is like inheritance.is'nt it?
That would limit you to one child. If you make a "join" table between them, it will allow you to have many children or parents. A join table row would contain keys for the parent and child.
Once again...if you use stored procedure calls you can encapsulate everything, hide implementation, and have loose coupling. Think of stored procedures as method calls.
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Saturday, December 29, 2012 1:58 AM
Points: 5,
Visits: 8
|
|
| Thanks for your instruction, i am familiar with junction table, but i look a way to implement something like inheritance. In addition i agree with you for encapsulating by stored procedures.
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: Yesterday @ 1:17 PM
Points: 8,641,
Visits: 8,273
|
|
tz.bahrami (12/27/2012) Thanks for your instruction, i am familiar with junction table, but i look a way to implement something like inheritance. In addition i agree with you for encapsulating by stored procedures.
Your request still doesn't make sense. If you MUST think of sql as objects think of the table as the object and each row as the instance and each column is the property. What you are describing is you want to inherit the row. This doesn't make sense because in OOP that would be like inheriting the properties of an instance. It doesn't work like that. You inherit the object.
I think that what you are really trying to do is to have a parent - child relationship in sql. This of course is not only possible, it is a fundamental base for normalized data.
Is the following example something along the lines of what you talking about?
create table #Parent ( ParentID int identity, SomeValue varchar(10) )
create table #Child ( ChildID int identity, ParentID int, SomeValue varchar(10) )
insert #Parent select 'Parent 1' union all select 'Parent 2'
insert #Child select 1, 'Child 1' union all select 1, 'Child 2' union all select 2, 'Child 3' union all select 2, 'Child 4' union all select 2, 'Child 5'
select * from #Parent p join #Child c on p.ParentID = c.ParentID
drop table #Parent drop table #Child
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Moden's splitter.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 9:31 AM
Points: 65,
Visits: 443
|
|
You can create views to "merge" two tables but they get tricky when you try to update columns from both tables.
You could create a wide table (sparse) containing all the sub-types as nullable columns and implement views on it to give you your subset that you can update.
|
|
|
|