Tag Info

New answers tagged

0

First of all: Be concistent within your columnnaming! In Type you use ID, in Customer you use CustID and in Orders CusomerID. Same with ToppingID vs ToppingCode. And you dont have to use the Prefix Pizza in the Pizzas (imho, plural is also not that nice) table. The relation Type is not clear to me. I guess you can put the OrderType directly into Orders. ...


0

You are getting the error as you are trying to script out OBJECT that is encrypted. You should read the error carefully as it is self descriptive : There are ways that you can use as described in my answer - How to view an encrypted view or stored procedure ? and here - Martin's answer.


0

No. "DDL statements (CREATE, ALTER, DROP) [...] cause an implicit COMMIT" Thanks horse with no name.


0

Remove user_profiles table and keep all user's personal data in one table. the user_profiles table is not storing any data about the nickname itself and you say a user can have no more than one nickname. I assume the nickname is optional. The only reason to have it in a separate table MIGHT be for performance to get a list of nicknames such as when a new ...


0

This might not be the answer but a general tip for designing is to remember that for your initial logical design. A logical relational DB schema is only made up of one-to-many relations. e.g. One Park has many Photos and One User has many photos. That allows for a many-to-many such as; A user may log photos for many parks and a park may have photos logged by ...


1

I talked to someone who helped me find the answer. The correct syntax is, for anyone in future reference. The documentation mentions it, although it can be easy to miss. START TRANSACTION; DROP SCHEMA IF EXISTS replays CASCADE; CREATE SCHEMA replays; CREATE ROLE admins WITH PASSWORD 'changeme'; GRANT SELECT ON ALL TABLES IN SCHEMA replays TO PUBLIC; ...


1

Approach 1 is the cleanest with no redundancy. However I can understand your worries about scanning through a huge table just to count a post votes. So approach 2 which features some "caching" seams fair. The downside is that you add some redundancy but this is not even the main issue. You also lose consistency. It's possible to have a post with 500 votes ...


0

Actually, keeping current and historical data in the same tables saves a lot more than a few where statements can overcome. Keeping data segmented (by year or otherwise) means you have to examine each query and change the target of the query itself. This usually involves dynamic SQL which is (and should be) always the last solution to consider. I've given ...



Top 50 recent answers are included