New answers tagged best-practices
0
Short answer: In general it is no good practice to dynamically create tables and columns. But there can be rare special cases there it is good practice.
Long answer:
You may run (at least) on the following problems with your solution:
A user can have only 1 garden, because the garden_id is in the table "users".
If you want to add some more infos to a ...
0
Yes, you are correct. Your preferred method matches with the fundamental idea of a relational database. Any app design that allows users to create or delete tables is pretty risky. Think of how much extra effort you will need to have in-place (for security reasons) to make sure that a critical table is not deleted or over-written by a new table. Plus, ...
4
I dont see anything wrong in your setup. To be fair, this is the correct way of setting up SSIS in a clustered environment.
Read up SSIS and clustering: What you should do instead
Also for the login failure, its worth to check the Windows Server 2008 R2's firewall rules to allow an inbound rule for either the msdtssrvr.exe executable or the DCOM port ...
1
Neither of the other 2 answers are correct.
John could live at 555 Main Street, and his wife, Shirley, could work there. It's a home and work address!
This is the correct schema:
PARTY
id
name
MAILING_ADDRESS
id
suiteOrApartment
streetAddress
city
postalCode
PARTY_MAILING_ADDRESS
partyId
addressId
purpose {work, home, ...}
You could include a ...
1
At the end of the day, #3 is still the BEST option.
We go with what we think is simple at that point but more often than not, business will come up with another reason to add one more type of address.
Design it correctly from the get-go! Good luck!
4
If you are really sure that those types don't change (or at least not often) you can also use a variation of 3) using a column AddressType of type varchar with a check constraint that limits the values to 'work' and 'home'.
This is less flexible than a lookup table, but still better than a boolean that has some implicit meaning when set to false. And you ...
1
That's not all that large of a table for full text indexing. When you hit hundreds of millions or billions of rows that where things that getting more complex.
As it is just setup the full text catalog and index to do auto population and auto change tracking (these are the defaults) and you'll be fine.
3
Full text in SQL Server should have no trouble keeping up with your workload. I currently support a full text index in SQL Sever that is approximately 500,000 rows with 125,000 rows being inserted and deleted everyday. Query load peaks at around 200 full text searches/sec. Response time it's fairly consistent in the .5 to 1.5 sec range.
...
3
Well one thing you may want to consider doing is validating your application(s) still work on a test instance that contains the same database and upgrading it to the newer service pack. While rare and usually changes are backward compatible, there could be behavior changes to things like the optimizer that would be impossible to guess exactly how they might ...
Top 50 recent answers are included
