What is the meaning of the blue line and the green line in MySQL workbench? - mysql-workbench

As shown in the figure, the Country table is combined with the City table by the green line, and the City table is combined with the Address table by the blue line. I can't figure out what's the meaning of the two kind of lines.

The connections show relationships (foreign keys). That should be clear.
When you hover with the mouse over a table figure, all connections are highlighted which either go out from or come in to that table.
Outgoing connections, that is, foreign keys defined on that table, which reference a different table are shown in green.
Incoming connections, that is, foreign keys defined in another table, which end on the current table are colored blue.
The referenced fields are colored the same way as their associated relationship.
Currently table city is active, so the foreign key from city.country_id to country.country_id is colored green (it's an outgoing connection). Table address has defined a foreign key to city, which is shown in blue. Now hover address and you will see that the connection color to city switches from blue to green.

Related

View primary key in DBeaver

Is there a quick way to view the primary key of a table in DBeaver? Like e.g. in the Eclipse data source explorer, where primary key rows are marked with "PK" and a special symbol.
For a given table, right click on the table name(in Database Navigator) -> select View Diagram.
This will open a window like this containing a single ER Diagram for the table -
In this diagram, the primary keys can be seen marked as bold under the table name, in the second partition.
To have a look at the primary keys of all the tables, in the Database Navigator, go to your database and then right click on public -> select View diagram. This will open the ER diagram for the whole database and the connections between the tables. Here, under each table name, the bold columns are the primary keys.
Note: A primary key can be a single key as well as a combination of multiple keys.
As per this github post, some database types (at least MySQL and PostgreSQL) show a small lightbulb to the left of the column name. This is visible in the Properties, Data and ER Diagram tabs.
Example with PostgreSQL:

Oracle SQL Developer diamon icon in model

I have created model in Oracle SQL Developer, in bottom there are 2 icons
1 is key (which is primary key) , 2nd is diamond ? what diamond showing ?
The diamond items show you the INDEXES on that table.
The red asterisk character to the left of the column name indicates the column has a NOT NULL constraint.
If we pull up the table in the database, we can see the indexes list and the model diagram side by side to verify.
In Oracle, a PRIMARY_KEY constraint automatically creates an INDEX of the same name, UNLESS you already have an INDEX and you tell the PRIMARY_KEY constraint to just re-use your existing INDEX.
The diamond is showing that it is a NOT NULL field.

Delete row from many-to-many table (VB.Net, .edmx)

I have Users and Regions. A User can be assigned to any number of Regions.
To implement this I have a table of Users, a table of Regions, and a third table UserRegion which is just UserID, RegionID (both columns form the primary key and they have foreign key relationships to the User and Region tables).
Entity Framework does not import the UserRegion table into my data model, instead it creates a property of each User object which is a list of Regions, and another on each Region object which is a list of Users. This is very useful except that I can't figure out how to un-associate a User from a Region.
The below code
Dim db as New DatabaseContext
Dim user = db.Users.Where(stuff).First()
user.Regions.Clear()
db.SaveChanges()
produces this error:
The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.
How can get rid of the relationship rows I don't want anymore?
I figured this out.
The relationship needs to be removed from both sides. So the code should be:
user.Regions.Clear()
For Each r in db.Regions
r.Users.Remove(user)
Next
db.SaveChanges()
Now I have a zillion for loops peppering this function but oh well. Hopefully this helps someone.

How to draw relationship-lines between columns?

Are there any options in MySQL Workbench to draw the relationship-line between the columns and not the tables? If i export my diagram as JPG i can't see, which columns are foreign keys and who they are related to.
On the screenshot, you can't see, that id and user_id are connected.
In the main menu bar go to: Model -> Relationship Notation -> Connect to columns.
I'm not sure MySQL Workbench can draw relationship lines between columns but you can aware that Primary Key is shown as Key Symbol and Foreign Key is shown as Red Diamond Symbol.

How do I create a drop down list?

I'm new to PostgreSQL.
I was wondering, how do I make a column a drop down list.
So i've got a table called Student. There's a column in there called "student_type", which means whether the student is a part time student, full time student or is sandwich course student.
So I want to make "student_type" a drop down list with 3 choices: "part time" student, "full time" and "sandwich".
How do I do this?
(I'm using pgAdmin to create the databse, by the way.)
A drop-down is a client side thing and should be dealt with accordingly. But as far as a relational database is involved there should exist a student_type relation with the id and type columns which you would query like this:
select st.id, st.type
from student_type st
inner join student s on s.type_id = st.id
group by st.id, st.type
order by st.type
The inner join is to make sure you don't show an option that does not exist in the student table and would therefore produce an empty result if chosen. In the client side the id should be the option value and the type the option text.
If there is no student_type relation as a consequence of bad db design or if you are only allowed to query a denormalized view, you can still use the student relation:
select distinct student_type
from student
order by student_type
In this case the student_type will be both the option value and the option text.
I think You use MS Access before. It is not possible to create such a drop-down list using pgAdmin, but it is possible to limit acceptable values in field "student_type" in a few different ways. Still, this will not be a drop-down or Combobox filed.
eg:
You can use a table with a dictionary and then use a foreign key,
You can use the constraint to check the inserted value
You can use a domain (the field is in the type of Your domain, and the domain is based on
proper constraint)
You can use trigger (before insert or update)
etc.
To put this a different way, Postgres is a database, not a user-interface
library. It doesn't have dropdown lists, text boxes, labels and all that. It is not directly usable by a human that way.
What PG can do is provide a stable source for data used by such widgets. Each widget library has its own rules for how to bind (that is, connect) to a data source. Some let you directly connect the visual component, in this case, the dropdown widget, to a database, or better, a database cursor.
With Postgres, you can create a cursor, which is an in-memory window into the result of a SELECT query of some kind, that your widget or favorite programming language binds to. In your example, the cursor or widget binding would be to the result of a "SELECT student_type FROM student_type" query.
As an aside, the values for "student_type" should not be stored only in
"student". You should have a normalized table structure, which here would give you a "student_type" table that holds the three choices, one per row. (There
are other ways to do this.) The values you specified would be the primary key column. (Alternatively, you'd have those values in a UNIQUE column with a
surrogate key as the primary key, but that's probably overkilling for a simple
lookup table.) The "student.student_type" column would then be a foreign key
into the "student_type.student_type" column.