New answers tagged schema
0
Checking default value doesn't make sense, as you have declared the static value which must be correct only. But the values which are going to be inserted manually are not checked using CHECK constrainst.
CREATE TABLE Company (
AccountID varchar(25),
Name varchar(20) NOT NULL,
Website varchar(255) DEFAULT 'https://sample.com',
...
0
si.to_char(date_issued, 'DD/MM/YYYY') as "Transaction Date" is attempting to invoke a function to_char() defined in the schema si, which is not what you want. You want to call the standard function on column date_issues of the relation si; this would be written as
to_char(si.date_issued, 'DD/MM/YYYY') as "Transaction Date"
Note the ...
0
I'm more of a fan of your second option because it's more normalized than the first option, but even better for normalization would be to have one Certificates table with the common fields in it ID, ApproveeID, ValidFrom, ValidUntil, StatusID and then a generic auxillary table to store the uncommon fields in.
For example, the auxillary table could be called ...
0
1:many -- Just an id in one of the tables to link to the other.
many:many -- Need a table to link them. It will have (probably) exactly 2 columns, namely the two ids.
key-value pairs -- read about EAV and its evils and benefits.
0
Tags are indexed string values meant for discrete sets of values. Tags can be queried in a WHERE clause, and can be used for grouping values with GROUP BY. Tags are ideal for metadata and a poor choice for data. Use a tag if you need such functionality and you have a bounded set of tag values.
Fields are typed values (can be string, but can be int, long, ...
1
Yes, it is not a good idea to use a dynamic (changing value) like an ObjectId as a field name. To query a specific bookmark you are looking for a specific value for a specific field. And also, to index bookmarks fields it is not possible as the field names are changing.
You can use something like this, for the bookmarks field:
bookmarks: [
{ post_id: &...
1
Select privileges on all SYSCAT objects are granted by default to the PUBLIC pseudo-group (unless the database is created as "restrictive"), so you shouldn't have ended up with users not being able to access syscat.schemata unless you or someone before you chose to actively prevent that.
What could go "wrong"?
Users will be able to ...
0
You should group the fields closest related to each other in the same Table and create additional Tables for the remaining fields as they relate to each other as well. This is called database normalization and is effective in reducing data redundancy, improving maintainability, and helps optimize performance. Your additional Tables (kind of reference Tables ...
Top 50 recent answers are included
