Tag Info

New answers tagged

1

You can use JPA with inheritance. There are several variations ("patterns"): all objects share the same table and there is a "discriminant" column/attribute (this is the closest to the one you explain). It is quick for queries, but you will have a column for each attribute of a subclass (if you have 20.000 instances, and only two instances of a subclass ...


0

The classic way to store a tree in a database is to use a self-referential table. If you take James Anderson's branch table and add an optional parentBranchID field, you are there. The only branch with a null parentBranchId will be the root node. Similarly, read the whole table into memory using branch classes that have both a parentBranchID and a ...


0

Your transaction table should not have to rely on the services table. That's because the moment a transaction is done, the relation to the services table is lost. Why? In the services table apparently the name of your service or the amount of the service can change. In a historical transaction table, the name and amount will be what it is at the time you ...


1

Branches is fairly easy: Root of tree is "1". First bifurcation results in branches "1x1" and "1x2" counting from the left. So the top rightmost branch in your tree is labeled "1x2x2x2". This schema is quite useful for querying as you can get all the sub branches of say "1x2" by a simple " LIKE '1x2%' " in SQL. Squirrel position is more problematic but ...


2

If you want to make sure there is an established list of services (a table to inner join) then you need to manage the changing of this table without breaking your joins for historical records. Use a soft-delete. Add a field to the list of services called: IsDeleted. Check it off when you no longer offer the service. The ID will remain. I would probably ...


6

The question should not be whether or not you need to use inner joins. The design is flawed. The flaw is that the transaction entity is missing a property, i.e., your transaction table is missing a column to record the amount of the operation. The other flaw is that the "amount" of a service is really its "price". Add an amount column to the transaction ...


1

You can use this structure too... Products: -------- ProductID | CategoryID | Title | Cost | TimeStamp 1 | 1 | Audi | $0 | ----- Specifications -------------- SpecificationID | Specification 1 | Model 2 | Fuel 3 | HardDisk ProductSpecifications: ---------------------- ProductSpecificationID | ...


0

In practice, Rails devs do this by using one of the gems for uploading and attaching images. E.g., Paperclip is maintained by Thoughtbot, very well tested and supports S3. And if you're interested, though, in experimenting and writing your own, you should take a look at Paperclip's source code to see what the current state-of-the-art is.


0

You can potentially mix 1 and 2 but create less work in the process. I would initially build your query logic on the assumption that all requests would be of the form "show all documents published on all websites" and then extend it to support filtering by tags (adding parameters to queries is easier than taking them away). You'd achieve this by simply ...


0

Just create helper class with static helper methods. Example: public class DataHelper { public static String asString(final Object value) { return asString(value, null); } public static String asString(final Object value, final String defaultValue) { if (value instanceof String) return (String) value; ...


0

Why not just pass the entire list into your database (restructured as a user-defined table type)? Then you can iterate over it in the stored procedure and take the appropriate action? If the row exists in the database, update it. If it exists for that invoice in the new table but not in the database, insert it. If it exists in the database but not in the new ...


0

It sounds to me like you 2 tables: a Product table, and an Image table. The Image table will have a foreign key back to the Product table and will store the image URL. This way, a single Product can have a bunch of Images. Product Image +-----------------+ +-----------+ |ProductID ...


1

Yes in general when using Table per Class Inheritance, the derived table has the same primary key as the base table. I personally prefer table per-hierarchy when possible because it doesn't require an extra join. It does create unused columns in the table which might be cumbersome with large hierarchies, but many modern databases support this scenario ...


4

Even fetching all details for just one hotel may results in a JOIN query from at least four tables, and scanning over all hotels records. A four-join query is absolutely trivial if you have the appropriate indexes for all joins. The second part of this question is far more troubling. Why the scan over all records? Is is because of missing indexes? ...


2

Why either/or? I've worked very successfully with a hybrid approach, using a relational db (SQL Server, but pick your favourite) to hold data that needs a relational structure - most of this is IDs linking all the various domain objects, very little textual data and certainly no blobs - and a nosql db (Dynamo) to hold large relatively unstructured data, ...


2

NoSQL is generally not very good with relational data. NoSQL is often great for non-relational but structured data like documents or time series. Your "one to many" relationships may look quite like a document: e.g a "hotel" document may carry all its images, room info, etc stored together and fetched with one operation. On the other hand, if you see a ...


4

I think that your search results can greatly improve through a number of techniques or database design approaches that will improve performance in your typical RDBMS. I suggest looking into and possibly prototyping the following improvements to see if they help you in performance testing first before you commit to an entirely new database technology that ...


1

You might want to consider using a noSQL database for this specific data. This way you can just put your object in a record, no matter what the 'columns' are. Depending on the chosen database system (and implemented solution), you would be able to 'overwrite' a record with different data if you want. Of course, you can also save your historic data and just ...


-1

The point of not denormalizing would be to avoid update anomalies. Not denormalizing would be good, if and only if: Users are moved from one account to another When a user is moved, all the Sales records for that user should implicitly move with the user to the user's new account In this case, 'denormalizing' is OK for three reasons: Users are ...


-1

If you treat this problem as a workflow problem, you can employ one of the workflow tools such as jBPM or Windows Workflow Foundation and focus on the business logic and let the tool handle the persistence for you.


5

Sounds like you have 3 major categories of data you are trying to store: General job data (job id, job requester id, job receiver id etc) State transitions (job started, job finished) State-specific job data (optional) job-related events (price changed, job receiver user reassigned etc) The key is to separate event-like data from everything else. Schema ...


4

How about a hybrid of the two? A large table with a JobID and state (and perhaps other information common to all jobs and states), with other tables to manage the additional state information. That reduces (or eliminates) the duplication of data, but keeps things more manageable.


0

Looks a fairly solid design apart from the college_major area which seems to be giving you problems as well :) Personally, I would split this table into two: Change the College_Major table to be a true many to many resolver (i.e. no intake int). This would become a reference table which is only changed when a college establishes a new major. Intake, which ...


4

You should get rid of the UserAccounts table, since the relationship between User and Account is a one-to-many relatioship (given the uniqueness constraint you have on UserAccounts). There's no need for the connection table where the relationship between entities is one-to-many. Such a table is only needed when the relationship is many-to-many. Let's ...


1

In this particular case, it doesn't sound like denormalizing to me--there is a 1:1 required relationship and the only piece of lookup information is the User key. Adding another table just to store the relationship doesn't add any value and actually works against you (since as you mentioned, you can't require the field that way). As for your reasons why, I ...


1

As far as I understood it a long time ago, in an exclusive arc a table contains a number of columns that are foreign keys to other tables, but only one of these can be set at a time (due to some logical constraint on the domain following from the real world). As this rule cannot be enforced on the database a corrupt record could be created where more than ...



Top 50 recent answers are included