|
|
|
|
|
|
by MarHoff
3339 days ago
|
|
|
But SQL isn't designed around objects with fields, it's designed around tables and rows. I think a more correct analogy would be that table are like classes, columns are the properties, and rows are instances. And so defining foreign keys is like setting a pointer to a parent instance. There is not direct analogy for methods, but you can use function/trigger to do the same job. PostgreSQL is actually an object-oriented RDMBS, it's not because you are meant to manipulate these objects through SQL that they are less powerful. And SQL is actually Turing Complete with PostgreSQL. It's clearly not convenient for general programming, but as soon as data manipulation is involved you benefit from a lot of built-in optimization. |
|
|
I can't agree with that statement, though I'm sympathetic to why you would say it. A foreign key is something that essentially doesn't translate from the world of Tables/Rows to the world of Classes/Objects.
In the relational data model the foreign key is a convenient place to include an index for joining on. What does join even mean between two classes? The closest you'll typically get is nested objects, but that's not quite right. A row produced from table joins isn't a nested data structure. It's still flat. The join operation in relational algebra has no direct equivalent in OOP.