Tag Info

New answers tagged

2

I see a few options depending on what you need: (1) if there are many unique instances that follow a common algorithm, (2) if there are many similar objects or you will generated objects at run-time, and (3) if you want to dynamically modify the object's behavior while running. Note: you can combine all of the patterns I mention here, if need be. If each ...


0

You should have very specific, semantic requests. For instance: You want to pull information about a specific owner example.com/owner/123 You want to pull information about a specific owner's assets example.com/owner/123/assets Now you want to pull all assets that belong to owner 123 example.com/ownerAndAssets/123 Or you want to pull a specific ...


1

I'm trying to determine when a web application should query a database for related data that may or may not be used in the current request. For such general questions it's hard to give a general answer. You have to consider two points: convenience and performance. Many things, which seem at first sight convenient are at hindsight performancekillers. ...


1

In your DAO layer, you should have a way to mark a relationship as required or optional (terms may vary based on whatever framework you use). Required relationships mean that if A links to B and I query A, the web service must return B as well. Use this for data where the two objects are always used together. Optional relationships mean that if A links to ...


1

I think it depends on complexity of the interface. If the set of calls that you can make against the database is going to be significant, then something like a REST service in front of the database would make sense to limit the server side implementation and support efforts. It will slow things down by being inserted into all flows but it will enable ...


-2

You should NEVER keep those things in DB. There are other places where you can store the information. Pulling data from DB is expensive and much better solution would be to store it as XML or even separate class and including that object into other classes. Then you would only need to change the code on one place AND you would avoid torturing your DB.


0

Both Have a central controlled table with: ID int PK Code varchar Then let app have table with: ID PK FK to central add as many flag columns as they want This way you still have one column for Code Another option is an app table CountryID FlagID Value This way your columns become rows Problem you have here is rewrite a lot of queries


4

The answer may be simpler than you might have originally thought: replace the "Countries" table shared across monolithic database-centric apps with a microservice, or simple webservice that exposes the same functionality with a simple REST call (note: I'm suggesting REST though that is not your only option, though it is probably the lightest-weight option). ...


0

Using a Hash or GUID as Primary Key is also bad idea because it causes Index Fragmentation and frequent Page Splits.


7

This former SO article tells you how to calculate the collision probability. For SHA-1, b is 160. The number of people living in austria is below 10 millions. Even if each living person in austria is registered in a hospital with a unique person/sector ID, that just makes a collision probability of less than 3.5 x 10^-35. I guess that should be small enough ...


4

Hashes will inevitably collide if they're smaller than all possible combinations of data. See this excellent answer: http://programmers.stackexchange.com/a/145633 If primary keys are not supposed to be meaningful (human readable; containing retrievable traits of data), I would just go with GUIDs. Yes, theoretically they can collide as well, but heat ...


1

For the above fields, if any of the above filed has opportunity in any time to have more than one value then that table should be split into multiple tables with one to many relationship. In case if all the fields required single time insertion at all time then no need to split it. This will lead you to third normal form.


6

While a high number of columns is a common denormalization smell, one can have a three-column table which is not normal and a 100-column table being completely normal. I see column names in plural, which tend to be worse smells (do Issues and HobbiesAndInterests contain comma-separated numbers or some evil thing?). There's also some columns which look like ...


2

It's not enough to list the fields in the tables, you also need to look at the values inside those field. You will see this in the first step, which is normalising it into First normal form. Then you can continue to Second normal form, and so on. Usually you only want to normalise your database to Third normal form. Each normal form has criteria that's easy ...


1

Just try to break it down into logical tables. Make one table for only contact information, one table for opportunities(i.e. WantsRecoveryCoach, WantsTelephoneRecoverySupport)that way the individual tables are simple enough to understand without needing over-complicated queries to sort the data. It also allows you to separate public information like names ...


1

Regarding the table, if a book can have many labels and a label many books (sounds quite reasonable) then that's a many to many relationship. In case of REST the many to many relation is in fact a bit confusing since we talk about resources and with the URI being a unique identifier it seems weird to be able to access one and the same resource from two ...


1

To me, there's no question. Go with Option 1. It makes sense that you'll have Products and Categories. They're different, and shouldn't be forced to live in the same table. However, a productName (reasonably shortened to 'name') is not the same as a categoryName (also reasonably shortened to 'name'). You can use context to figure out which 'name' you ...


1

Yes if ManipulatedEmployeeCheckIn[Id,FirstIn,FirstOut,SecondIn,SecondOut] contains redundant data which is also in EmployeeCheckIn[ Id,CheckIn,Type,Status] Yes in general NULL values should be avoided if possible This depends on your intention which seems to be contradicting your question. If you want to use EmployeeCheckIn[ Id,CheckIn,Type,Status] as a ...



Top 50 recent answers are included