Various documents define row as being synonymous with record. Unfortunately, a record can be a list or a single item. All the same, a row usually contains more than one item but is sometimes called "a single entry".
A field can be a container (for example, in html), which could be considered a place to input one item, or it could be considered a place where many items are entered (albeit on different occasions, sometimes).
It sure would be nice if someone could put it in simple terms. For example, a row is the result of a single-item, single-field entry via an insert statement. A field represents all rows and intersects a column.
Can anybody provide a clear answer because google just isn't cutting it. Thank you.
Edit:
In excel it sure is cut-and-dry. Column is all horizontal. Row is all vertical. Cell is a row-column pair; a single entry. Even though relational database languages are like working with multiple spreadsheets (tables), the column, row, cell approach seems to make the most sense.
I am looking at various different explanations that don't seem to agree with one another in the answers. Can we operationally define the terms for the tutorial I am presently working on, which is not clear? Link: http://zetcode.com/databases/sqlitetutorial/introduction/#about
If this is a table...
O--O-------------O-------------O
|ID| my_col_1 | my_col_2 |
O--O-------------O-------------O
|0 | fskdjfh | jfkhgdkfj |
|1 | NULL | hfkjsdh |
|2 | jfkdhsdkjh | NULL |
|3 | fdfhkjh | NULL |
|4 | NULL | NULL |
O--O-------------O-------------O
This is a row...
|0 | fskdjfh | jfkhgdkfj |
And this is a field...
| jfkhgdkfj |
Hows that?
Imagine you have to describe many aspect of the same thing. You have to choose which aspects you want to take care of: these are the columns of your table. For each of the column you can choose the data type to represent (numeric, String, ...). The column could be also a composite data type (ex: date) or a reference to another object.
The description of an object consists in all the values contained in the columns relative to that object: this is the row/record (the two terms have the same meaning in ER databases).
The field is the value assumed by a column--let's say that it is a cell in a table. It is part of the row, but it may have no sense outside the context provided by the row and the columns.
Maybe the confusion is due to the fact that to simplify the notation, the term field is used as the term column. When you see a query like "select * from foo where somefield=something" it means that you select the rows in which the field relative to the column "somefield", assumes the value "something".
This definition is ok also with HTML fields. A field of a form is the place where you enter the value the column will have in your case, that means, in the row that represents you.
One row/record, one column/field:
+---+
| x |
+---+
One row/record, three columns/fields:
+---+---+---+
| x | y | z |
+---+---+---+
Three rows/records, one column/field:
+----+
| x1 |
+----+
| x2 |
+----+
| x3 |
+----+
Three rows/records, three columns/fields:
+----+----+----+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| x3 | y3 | z3 |
+----+----+----+
fields or columns are defined with the table, and are the part of table structure, they hold information vertically. they describe the records or rows in the table.
Example: name, age, salary etc.
Rows or records are the real data that is stored in the table, these records are the actual information. one horizontal row represent one record.
Example: 'John', 23, 23000.00
Related
consider the following table:
+------+------+----------+----------------+
| Col1 | Col2 | Col3 | Numeric Column |
+------+------+----------+----------------+
| ValA | ABC | Value 3 | 101 |
| ValF | DEF | Value 10 | 101 |
| ValC | DEF | Value 10 | 101 |
| ValB | GHI | Value 12 | 103 |
+------+------+----------+----------------+
I would like to find duplicate rows by comparing values across multiple columns, and highlight the values in the [Col1] column when duplicate rows are found (OR highlight the whole row, whatever is easier). So in the above table I would like to compare values of the [Col2], [Col3] and [Numeric Column] columns.
And in this example, ValF and ValC in [Col1] would be highlighted. I am not sure how to go about this.
I figured it out, see steps below.
Create a dimension variable and concatenate all the columns you like to compare into a variable.
Variable name: Concat_col
Variable formula: =[Col2]+[Col3]+[Numeric Column]
Create a measure variable and refer to the first variable.
Variable name: Count_col
Variable formula: =RunningCount(NoFilter([Concat_col]);([Concat_col]))
Create a measure variable and refer to the first and second variable.
Variable name: Max_col
Variable formula: =Max(NoFilter([Count_col])) In ([Concat_col])
Now create a Formatting rule:
And populate as follow:
To apply to a whole row, select the columns one by one and click Formatting Rules > 'Conditional Format' (this is the name of the formatting rule we just created earlier).
I have a situation in MS Access database that I must prevent duplicate records based on combination of three attributes:
StudentNumber
ColleagueID
TypeOfAttending
So, for one combination (StudentNumber & ColleagueID) I have three types of attending: A, B and C.
Here is an example:
+---------------+-------------+---------------+
| StudentNumber | ColleagueID | AttendingType |
+---------------+-------------+---------------+
| 100 | 10 | A |
| 100 | 10 | B |
| 100 | 10 | C |
| 100 | 11 | A |
| 100 | 11 | B |
| 100 | 11 | C |
| 100 | 11 | C |
+---------------+-------------+---------------+
So last row would not be acceptable.
Does anyone have any idea?
As noted, you could choose all 3 as a PK. Or you can even create a unique index on all 3 columns. These two ideas are thus code free.
Last but least, you could use a Before change macro,and do a search (lookup) in the table to check if the existing record exists. So far, given your information, likely a unique index is the least effort, and does not require you to change the PK to all 3 columns (which as noted is a another solution).
So, you could consider a before change macro. And use this:
Lookup a Record in MyTable
Where Condition = [z].[Field1]=[MyTable].[Field1] And
[z].[Field2]=[MyTable].[Field2] And
[z].[ID]<>[MyTable].[ID]
Alias Z
RaiseError -123
Error Description: There are other rows with this data
So, you can use a data macro, use the before change table macro. Make sure you have the raise error code indented "inside" of the look up code. And note how we use a alias for the look up, since the table name (MyTable) is already in context, and is already the current row of data, so we lookup using "z" as a alias to distinguish between the current row, and that of lookup record.
So, from a learning point of view, the above table macro can be used, but it likely less work and effort to simply setup a uniquie index on all 3 columns.
This question already has answers here:
Return rows in the exact order they were inserted
(4 answers)
Closed 4 years ago.
I don't know whether it is already answered. I hadn't got any answers.In Mysql tables, the rows will be arranged in the order of primary key. For example
+----+--------+
| id | name |
+----+--------+
| 1 | john |
| 2 | Bryan |
| 3 | Princy |
| 5 | Danny |
+----+--------+
If I insert anothe row insert into demo_table values(4,"Michael").The table will be like
+----+---------+
| id | name |
+----+---------+
| 1 | john |
| 2 | Bryan |
| 3 | Princy |
| 4 | Michael |
| 5 | Danny |
+----+---------+
But I need the table to be like
+----+---------+
| id | name |
+----+---------+
| 1 | john |
| 2 | Bryan |
| 3 | Prince |
| 5 | Danny |
| 4 | Michael |
+----+---------+
I want the row to be concatenated to the table i.e.,
The rows of the table should be in the order of insertion.Can anybody suggest me the query to get it.Thank you for any answer in advance.
There is in general no internal order to the records in a MySQL table. The only order which exists is the one you impose at the time you query. You typically impose that order using an ORDER BY clause. But there is a bigger design problem here. If you want to order the records by the time when they were inserted, then you should either add a dedicated column to your table which contains a timestamp, or perhaps make the id column auto increment.
If you want to go with the latter option, here is how you would do that:
ALTER TABLE demo_table MODIFY COLUMN id INT auto_increment;
Then, do your insertions like this:
INSERT INTO demo_table (name) VALUES ('Michael');
The database will choose an id value for the Michael record, and in general it would be greater than any already existing id value. If you need absolute control, then adding a timestamp column might make more sense.
Just add another Column Created (Timestamp) in your table to store the time of insertion
Then use this Command for insertion
insert into demo_table id, name,created values(4,"Michael",NOW())
The NOW() function returns the current date and time.
Since you are recording the timestamp, it can be also used for future reference too
It's not clear why you want to control the "order" in which the data is stored in your table. The relational model does not support this; unless you specify an order by clause, the order in which records are returned is not deterministic.. Even if it looks like data is stored in a particular sequence, the underlying database engine can change its mind at any point in time without breaking the standards or documented behaviours.
The fact you observe a particular order when executing a select query without order by is a side effect. Side effects are usually harmless, right up to the point where the mean feature changes and the side effect's behaviour changes too.
What's more - it's generally a bad idea to rely on the primary key to have "meaning". I assume your id column represents a primary key; you should really not rely on any business meaning in primary keys - this is why most people use surrogate keys. Depending on the keys indicating in which order a record was created is probably harmless, but it still seems like a side effect to me. In this, I don't support #TimBiegeleisen's otherwise excellent answer.
If you care about the order in which records were entered, make this explicit in the schema by adding a timestamp column, and write your select statement to order by that timestamp. This is the least sensitive to bugs or changes in the underlying logic/database engine.
I wanted to ask you which could be the best approach creating my MySQL database structure having the following case.
I've got a table with items, which is not needed to describe as the only important field here is the ID.
Now, I'd like to be able to assign some attributes to each item - by its ID, of course. But I don't know exactly how to do it, as I'd like to keep it dynamic (so, I do not have to modify the table structure if I want to add a new attribute type).
What I think
I think - and, in fact, is the structure that I have right now - that I can make a table items_attributes with the following structure:
+----+---------+----------------+-----------------+
| id | item_id | attribute_name | attribute_value |
+----+---------+----------------+-----------------+
| 1 | 1 | place | Barcelona |
| 2 | 2 | author_name | Matt |
| 3 | 1 | author_name | Kate |
| 4 | 1 | pages | 200 |
| 5 | 1 | author_name | John |
+----+---------+----------------+-----------------+
I put data as an example for you to see that those attributes can be repeated (it's not a relation 1 to 1).
The problem with this approach
I have the need to make some querys, some of them for statistic purpouses, and if I have a lot of attributes for a lot of items, this can be a bit slow.
Furthermore - maybe because I'm not an expert on MySQL - everytime I want to make a search and find "those items that have 'place' = 'Barcelona' AND 'author_name' = 'John'", I end up having to make multiple JOINs for every condition.
Repeating the example before, my query would end up like:
SELECT *
FROM items its
JOIN items_attributes attr
ON its.id = attr.item_id
AND attr.attribute_name = 'place'
AND attr.attribute_value = 'Barcelona'
AND attr.attribute_name = 'author_name'
AND attr.attribute_value = 'John';
As you can see, this will return nothing, as an attribute_name cannot have two values at once in the same row, and an OR condition would not be what I'm searching for as the items MUST have both attributes values as stated.
So the only possibility is to make a JOIN on the same repeated table for every condition to search, which I think it's very slow to perform when there are a lot of terms to search for.
What I'd like
As I said, I'd like to be able to keep the attributes types dynamical, so by adding a new input on 'attribute_name' would be enough, without having to add a new column to a table. Also, as they are 1-N relationship, they cannot be put in the 'items' table as new columns.
If the structure, in your opinion, is the only one that can acheive my interests, if you could light up some ideas so the search queries are not a ton of JOINs it would be great, too.
I don't know if it's quite hard to get it as I've been struggling my head until now and I haven't come up with a solution. Hope you guys can help me with that!
In any case, thank you for your time and attention!
Kind regards.
You're thinking in the right direction, the direction of normalization. The normal for you would like to have in your database is the fifth normal form (or sixth, even). Stackoverflow on this matter.
Table Attribute:
+----+----------------+
| id | attribute_name |
+----+----------------+
| 1 | place |
| 2 | author name |
| 3 | pages |
+----+----------------+
Table ItemAttribute
+--------+----------------+
| item_id| attribute_id |
+--------+----------------+
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
+--------+----------------+
So for each property of an object (item in this case) you create a new table and name it accordingly. It requires lots of joins, but your database will be highly flexible and organized. Good luck!
In my Opinion it should be something like this, i know there are a lot of table, but actually it normilizes your DB
Maybe that is why because i cant understant where you get your att_value column, and what should contains this columns
I'm trying to access a field being called from the parent query within a nested one and here is my table
TABLE: reminders.
Columns: id:PK, rid:VARCHAR, title:VARCHAR, remind:Integer, start_day:DATE
SELECT id, remind, rid, title
FROM reminders
WHERE DATEDIFF(start_day, NOW()) <= (SELECT LEAST(3, remind))
Basically the second "remind" column in the LEAST() command is suppossed to reference the first "remind" column value for every row being spanned but for reasons that I can't just imagine i keep getting unexpected returns.
EDIT
In response to Sir Gordons that i provide more detailed info, I will try my best but I really do not know how to present table data here, but i'll try.
So basically i'm trying to SELECT all items from the reminders table WHERE the DIFFERENCE between the SET DAY (start_day) and TODAY doesn't exceed one of TWO values, those are either 3 or the value set in the remind column of the current row. Basically if the value set there is less than 3 then it should be used instead, but if it exceeds 3, 3 should be chosen. Here's a visual of the table.
+---+-----------------+--------------------+-----------------+-------------+
|id | rid | title | start_day | remind |
+---|-----------------|--------------------|-----------------|-------------|
|1 | ER456GH | This is real deep | 2014-01-01 | 10 |
|2 | OUBYV90 | This is also deep | 2014-01-13 | 10 |
|3 | UI90POL | This is deeper | 2014-01-13 | 60 |
|4 | TWEET90 | This is just deep | 2014-01-14 | 0 |
+---+-----------------+--------------------+-----------------+-------------+
So in editing this I realized that there was a false table entry under remind on the 4th entry that was causing it to pull false (i.e where remind = 0). Sigh. Some serious short sight on my part/lack of sleep I guess. The query does work . Thanks again.
You don't need a subquery here. Does this work?
SELECT id, remind, rid, title
FROM reminders
WHERE DATEDIFF(start_day, NOW()) <= LEAST(3, remind);