Question
I have a table MyRelations that holds the Many-To-Many relationships for my table MyAccounts. Now I need to determine the betweeness centrality between MyAccounts for all rows.
How can I find this using pure SQL ?
Model
Table MyAccounts : Id, Name
Table MyRelations : Id,ForeignKeyA, ForeignKeyB
Additional
I am trying to achieve this with PostGreSQL
Any ideas ? Google seems to be not helping with straight forward examples to base myself upon.
Related
I have a question about whether I can extract indirect relationship information from a SQL database, just using SQL.
A modelling tool I'm using is based upon an SQL database that essentially has just two tables: Elements and Relations. The table definitions are as follows
Elements:
id, type, name
Relations:
id, type, name, source, target
Elements is just a list of entities with a system generated unique ID, and Relations (also with a unique Id) uses the Elements' unique IDs to define relationships between them in the 'source' and 'target' columns.
What I'm trying to figure out is: for any two elements in the model, e.g. A and D, or A and E, in the diagram below - are they linked, and if so how - including by multiple indirect relationships through other elements?
I know I could solve this problem by writing some procedural code that recursively trawls the Relations table exhaustively checking each relationship between A and D (or E). But this is not straightforward to code.
So I wondered if anyone can point me at the best solution to this problem?
Specifically, is there an SQL-only solution to this problem or will I have to write some procedural code?
The SQL DB in question is alaSQL underpinning the Archi modelling tool. But I'm also interested if other solutions, as pumping the data into a new DBMS is not a problem.
Thanks.
Hi there I'm knew to SQL and I'm facing what I hope is a basic problem.
Scenario: Say I have 2 tables, let these be Client and Reading. I want to find the table k which holds a relationship to both of them, so that I may perform an inner join to link Client to Reading.
Question: Does a query exist to find table k?
p.s.Client and Reading have many attributes which makes finding a relationship by hand very tedious.
If the tables have foreign keys, then yes you can query the meta tables to find the tables that have relationships to them.
If not, then no, there is no way to find them programmatically.
I have over 100 basic types in my project. Assume that all of them just contains an Id and a Title , so which of these approach is better to use :
Approach 1 : create a separate table for each of them
Approach 2 : Create a table for all of them and use another field as discriminator
I am using Using MSSQL server with Entity Framework Code-First Approach . Actually I can not decide which approach I should choose to use.
I think the question is self-briefed , but Let me know if you need more details.
UPDATE1 : Please do not refer me to this question . I have checked this one , wasnt that much helpful
UPDATE2 : Many of these tables have many relations to the other tables. but some of them wont use that much
100 types that inherits from Id/Title base type and EF TPH (so the DB will have 1 table with discriminator and programmers will have 100 types).
Approach1 will keep relation integrity and clean navigation properties form models.
Also your IDE will helps you completing rigth model names.
The tip: create and interface for all tables in order to reuse UI controls.
Edited
If you found a business name for this table, like customer_data then do a single table. If name is related with technology master_tables split into full semantical classes.
I am trying to figure out what the best way to design this database would be. Currently what I have works, but it requires me to hard-code values where I would like it to be dynamic in the future.
Here is my current database design:
As you can see, for both the Qualities and the PressSettingsSet tables, there are many columns that are hard-coded such as BlownInsert, Blowout, Temperature1, Temperature2, etc.
What I am trying to accomplish is to have these be dynamic. Each job will have these same settings, but I would like to allow the users to define these settings. Would it be best to create a table with just a name field and have a one-to-one relationship to another table with a value for the field and a relation to the Job Number?
I hope this makes sense, any help is appreciated. I can make a database diagram of how I think it should work if that is more helpful to what I am trying to convey. I think that what I have in mind will work, but it just seems like it will be creating a lot of extra rows in the database, so I wanted to see if there is possibly a better way.
Would it be best to create a table with just a name field and have a one-to-one relationship to another table with a value for the field and a relation to the Job Number?
That would be the simplest - you could expand that by adding data-effective fields or de-normalize it by putting it all in one table (with just a name and value field).
Are the values for the settings different per job? If so then yes a "key" table" with the name ans a one-to-many relationship to the value per job would be best.
I need some advice on modelling my data tables. I need to apply inheritance hierarchy on my tables using SQL Server and Hibernate. Could anyone show me a basic example? It could be a tutorial on website too.
Cheers...
Set up the tables so that the derived table shares primary key with base table.
MS SQL Server isn't an object-orientated database, it is a relational database. It sounds like you should be using views over your base tables rather than duplicating columns.
Duplicating columns is unnecessary and would no doubt impact performance and maintenance would become a nightmare.
Maybe edit your question to include more details on what you are trying to achieve.
Another way is to duplicate attributes in child tables and make parent table as VIEW (that selects by common attributes from all children).
CREATE VIEW Parent
AS
SELECT ID, Name FROM Child1
UNION ALL
SELECT ID, Name FROM Child2 ...
The problem could be with ID that should be unique through all the child tables (using GUIDs is preferrable)