I am really new to access. I have a calculated field(Name) in my Table which consist of 3 short text fields (fName + mName + lName).
I want to prevent any duplication in the calculated field (Name).
You can simply create a key using all three columns e.g.
CREATE TABLE myTable
(
fName VARCHAR( 25 ) NOT NULL,
mName VARCHAR( 25 ) NOT NULL,
lName VARCHAR( 25 ) NOT NULL,
UNIQUE ( lName, fName, mName )
);
Note the order of the columns in the key may be important if it will form the clustered index for the table (i.e. how it is physically stored on disk). Not sure whether this can be done using the MS Access user interface.
Store a calculated field isn't good idea (because you provide redundancy of data in the database). Can you calculate that value within real fields values on the fly on the form/query or other GUI?
To avoid duplicate data just create unique key/index for real fields
Related
Let's assume a functional dependency: R(A,B,C,D) & FDs{ A->B, A->C, (B,C)->D }
A can identify any tuple. Defining A as a primary key, we can implement the dependency hold between A and others. But the combination of B & C can also uniquely identify D.
CREATE TABLE `test` (
`A` INT NOT NULL ,
`B` VARCHAR(100) NOT NULL ,
`C` VARCHAR(100) NOT NULL ,
`D` VARCHAR(100) NOT NULL,
PRIMARY KEY (`A`)
);
This SQL only contains the dependency between A and others. But this SQL does not say that B,C can also uniquely identify D.
Is it possible to define the dependency between B,C and D using a single table in MySQL?
I think one way is to use another table. One table for R(A,B,C) & FDs{ A->B, A->C }. And another table for R(B,C,D) & FDs{ (B,C)->D }. However, I would like to use a single table.
If ssn is the PRIMARY KEY, then GROUP BY should be happy. Please provide the SQL that is giving you trouble, plus the SHOW CREATE TABLE.
Is this valid: name = CONCAT(fname, ' ', lname)? If so, then you should not be storing name. It is a no-no in databases to have redundant information.
You could have a virtual "generated" column instead of an actual name column.
I create a table with the following SQL using oledbconnection or immediately in access (installed version Office 365 MSO 32-bit and ACE 2016 32-bit):
CREATE TABLE Ticket (
[ID] COUNTER
, [Kundennummer] CHAR(15)
, [DC] CHAR(5)
, [Auftragsnummer] CHAR(25)
, [OZ] CHAR(5)
, [ASS] CHAR(20)
, [ASB] CHAR(5)
, [SPATZ] CHAR(19)
, [Status_num] INTEGER
, [Status_text] CHAR(255)
, [Bearbeitet_timestamp] DATE
, [IMPORT_ZEITSTEMPEL] DATE
, [RESULT_ZEITSTEMPEL] DATE
, CONSTRAINT [PrimaryKey] PRIMARY KEY ([ID])
);
The created table with "create table" always has the full restricted length for all fields with restricted length.
When I add a record in Access or via oleDbConnection, every field is padded to its full length with spaces.
How can I write the Create Table SQL in such a way that the table is created in such a way that only the actual field content is accepted. Or is there a setting in Access?
A table created with Access does not show this behavior.
Please help,
thank you
Use a VARCHAR field for a character field of varying length.
CHAR is fixed length so always needs to be fully filled, and pads with spaces if it isn't. While the GUI in Access doesn't support creating them, Access handles them just fine and just like most RDBMSes would.
How to create customize primary key in MySQL?, example i have table and the table name is X, I have a table field as ID,Code,Name.
I am afraid if I have 1000 users and when they input together will
result in destruction
and i want to :
INSERT INTO `X` (`ID`,`Code`,`Name`) VALUES
('P3K','Alex'), // this primary key is "P3K-1"
('SOS','Force'), // this primary key is "SOS-1"
('P3K','Bash'), // this primary key is "P3K-2"
Right now, i using TRIGGER (BEFORE INSERT) for this, like this one:
SET NEW.`ID` = CONCAT(NEW.`Code`,'-',IFNULL(SUBSTRING_INDEX((
SELECT `x`.`Code` FROM `X` WHERE
X.`Code` = NEW.`Code` and
ORDER BY X.`Code` DESC
LIMIT 1 ),'-',-1),0) + 1))
I did not try this code, but my point is:
User insert
Before insert I checking LAST Primary
IF Null then i set 0, else i cut the symbol (-) and take the last part
I increments (using [+ 1])
Final, i concat CODE and New Number.
am i misguided? LOL, and if true, how to create like this one?
(I THINK) We can do it and maybe no one knows about this, how does AI in MySQL work so perfectly?
Answer from him (https://stackoverflow.com/users/1133682/mjh)
InnoDB is very dependent on PRIMARY KEY using Auto Incremment, if you do not use Auto Incremment then you will spend space. each line by adding at least 6-8 bytes just to make the "HIDDEN PRIMARY KEY", and the best use of innoDB is USE Auto Incremment and do not disturb that key, if you want to add UNIQUE KEY then you just have to CONCAT
Instead of having the hyphenated string as the primary key, you can store the code and number as separate fields, use them together as the primary key, and optionally have the hyphenated string as a generated column. This is how CREATE TABLE would look for such a table
CREATE TABLE X (
Code CHAR(3),
Number INT,
Name VARCHAR(20),
CodeNumber VARCHAR(8) AS (CONCAT(Code, '-', Number)),
PRIMARY KEY (Code, Number)
);
Then you BEFORE INSERT trigger becomes
SET NEW.Number = (1 + IFNULL((SELECT Number FROM X WHERE Code = NEW.Code
ORDER BY Number DESC LIMIT 1), 0))
I have a table in SQL Server 2008 like this:
Column DataType
-----------------------
FID numeric(18, 0)
Name varchar(50)
DOB datetime
MobileNo numeric(18, 0)
EmailId varchar(50)
add1 varchar(50)
add2 varchar(50)
add3 varchar(50)
Pincode numeric(18, 0)
UpdateDate datetime
In this table FID should be changed to varchar(50) without dropping (deleting) the table..
How to do this and also FID is set as primary key to the above table and also as a foreign key to other tables
As I said - I would leave the column FID as it is - otherwise, you'll have a ripple effect throughout your entire data model, and this is really really not what you want to do.
What you can do is this: create a new, separate column that contains that new prefix that the "hgiher ups" are so desperate for, and concatenates this with the FID value - but it's a separate column, and you don't need to change any of the references at all.
ALTER TABLE dbo.YourTable
ADD FID2 AS 'MU' + CAST(FID AS VARCHAR(20)) PERSISTED
With this, you'll get a VARCHAR typed new column called FID2 which will have values like MU1, MU2 ..... and so on - automatically, no changes necessary, no messy table re-creations and data copying.... it just works!
Tools->Options->designers->(Unmark)Prevent saving changes that require table recreation
Right click table -> Design -> Change the numeric(18, 0) to varchar(50) -> Save
It will ask for confirmation since changing from one data type to another removes certain precision values.
The best practice is to keep Primary and foriegn keys unique numbers. But you may opt for unique code values too which are varchar values
And one more thing, changing the primary key field datatype automatically changes the datatype of all relational foreign key fields in other tables too.
This is my table schema,
below am is the schema for feedback table functionality,
please give good suggestion for the length and naming sense for the table and its fields,
please share your suggestion about the table schema and its length and naming conventions.
CREATE TABLE `mytest`.`tbl_feedback` (
`feedback_id` INT( 30 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`first_name` VARCHAR( 50 ) NOT NULL ,
`last_name` VARCHAR( 50 ) NOT NULL ,
`email_id` VARCHAR( 150 ) NOT NULL ,
`comment` TEXT NOT NULL ,
`cur_timestamp` VARCHAR( 20 ) NOT NULL ,
`ipaddress` VARCHAR( 20 ) NOT NULL ,
`status` INT( 3 ) NOT NULL DEFAULT '0'
) ENGINE = MYISAM ;
also i saw in this thread varbinary,
here they said use varbinary isntead of varchar, why should we go for varbinary, what is the advantage
Try to place fixed length fields (such as 'status') before the variable length fields. This won't make any difference whatsoever to the logic, but the program should run slightly faster when accessing those fields.
Here are just a few observations:
Table name "tbl_feedback" - This is a personal preference, but I would remove the "tbl_" prefix - I've never run into a case where I've found it useful to have prefixes on database objects.
email_id - I would take off the "_id" suffix. ID is a common naming convention for key columns (primary or foreign), and you seem to be using that convention too. In your case, it doesn't seem like email_id is a foreign key though, so just "email" might be better.
cur_timestamp - A name like "created_date" or "updated_date" might make a little more sense. With cur_timestamp, it's not really clear what the column is for, or if you're supposed to update it when you update the record... etc. Also, for this column, it might be useful to use a built-in type that can represent a date, rather than a varchar.
ipaddress - Just a nitpick, but based on your naming convention, it might be better if this was "ip_address". Also, you probably want to make this column at least 40 characters or bigger, so you can store IPv6 addresses (in the common notation).
status - does this column point to another "status" table? If so, should this be a foreign key named "status_id"?
Some of the fields look they the could be normalized.. like status as foreign key constraint, to a status table, and people as a separate table with a personid as a FK. Then you could do cool things like look up all feedback by person, or delete all by person, etc.