Tag Info

Hot answers tagged

60

There's a joke I heard awhile back: Q How does a BASIC coder count to 10? A 1,2,3,4,5,6,7,8,9,10 Q How does a C coder count to 10? A 0,1,2,3,4,5,6,7,8,9 Q How does a DBA count to 10? A 0,1,many The truth behind this joke is that once you have two (or more) of the same thing in a database structure (columns or tables), you're doing it ...


7

It's a terrible idea to be honest and there are a handful of immediate issues with that I can think of off the top of my head:- modifying the table structure becomes very difficult because of the number of tables you need to modify. you have to grant rights the app to change the table structure which is opposite to the principle of 'least privilege'. ...


6

Option 2 is a traditional master/detail setup. That is probably what you want here. Put the list id in the items table, and join on that. The schema shouldn't impact the JSON. Your query might look something like: select lists.name as list_name, items.name as item_name from items join lists on (lists.id = items.list_id)


5

Don't do this. Plain and simple, that's a terrible data tier pattern. It is bad for the following reasons: Doesn't scale well at all (rows should be created with new data, not objects) Data access patterns will suffer (it will be a pain, best case scenario, to construct your data queries. Worst case scenario you will cause extremely poor performance and ...


5

Your latter strategy is likely the better choice. It will be difficult to find all the problems in the data while it is still resting in its current format. I would treat this an ETL process of sorts, combined with an iterative approach. Something like this: Build a beta version of the schema. Write a program to read the old data, scrub/transform it, and ...


3

Add a field main_address_id in the User entity or table that holds the ID of the Address record that is the main one. Make that a one to one relationship, if you like. The only solution I have now is to create another One-to-One relationship between Users.main_address and Address but this does not insure that the main_address will actually be part of ...


3

Indeed, you could have been using PDO directly. The only real thing it does is to rethrow PDOException as RunTimeException, a practice which should be avoided at all costs. This being said, PDO doesn't keep you from having to create special adapters for a given database, since different databases have different syntax and functionality which cannot possibly ...


3

I wouldn't try to tie your UI representation or transmission of data to the UI directly to how you intend to store the data. By keeping the two separate and using some middleware logic to marry the two allows you to easily alter either side without possibly impacting the other in a critical way. From a data storage perspective, you would likely use option ...


2

Your solution is not relational and has a lot of disadvantages, to name a few: nearly impossible to do some queries involving data for multiple users no constraints can be used, therefore no consistency of your data hard to deal with privileges hard to migrate (if user ID is somehow changes, you're done) There probably should be those tables: users, ...


1

flask-restless supports this behaviour with it's multiple patch feature. PUT /api/person Sets specified attributes on every instance of Person which meets the search criteria described in the q parameter. I still don't know the name for this general technique, but this does what I need.


1

Mostly, you have little recourse and nobody to blame should you run into trouble. That's about it. The product itself is the same AFAIK. (Side note / flamebait: I would strongly recommend prototyping/benchmarking your load before committing to MongoDB. You will get surprised - sometimes badly - by its performance if you just transpose your SQL assumptions). ...


1

The way you are planning to do migrations is essentially the same way that Entity Framework does it for .NET applications. It has a DatabaseMigrations table with a key that is the date/time with a unique string appended to it. The code in a particular release is designed to work with a particular version of the database. It looks for the most recent ...


1

According to Oracle Database environments encapsulate one or more databases So an example of dealing with more than one database: one database for the Accounting package, one for the HR system, possibly on the same server (depends on your licencing model) and you're concerned with the interfaces between them that are required to pay your wages...


1

UNION in and of itself will deliver DISTINCT results. UNION ALL is faster than UNION, but it does not remove duplicates. Including DISTINCT in a UNION query does not add anything.


1

This is the classic single-tenant vs multi-tenant dilemma. To service multiple clients, should you: Have a single database that includes the data for all your clients (i.e. make them all tenants of your single database), or Have multiple databases, with each client partitioned off and the single tenant interacting with just its own database. Most of the ...


1

In my experience (and it's possible others will have other experiences), an application that modifies its own schema directly is usually a sign of a bad design, and it is probably unnecessary. I've yet to work on an application where the schema itself needed to change dynamically at runtime. If you start modifying your schema dynamically from your ...


1

Data definition language (DDL) statements are rarely used anywhere. Often, they are used in scripts that are processed by a SQL front end, initiated manually. However, programming the SQL front end requires that some Java (C, C++, what have you) programs are directly applying DDL on the database. Similarly, if you have a large application, it is often ...


1

What you have called "Table Per Hierarchy" resembles what Martin Fowler and others have called "Class Table Inheritance". See Diagram. I would call this mimicking inheritance rather than implementing inheritance. One technique that can be used to good advantage in some cases of class table inheritance is called "shared primary key". See tag wiki in SE. ...


1

Going with that last option in your edit but altering it a little. In this, you abstracted away any changes in concrete class. In your database however, you are saving the value of an enum that saves which kind of concrete class you are referring to, and what that concrete class' id is. This info can be passed to the factory, which should provide a ...


1

It makes a difference of what ClassA and ClassB really represent - generic names are not helpful for making good design decisions. For example, if those are things which can or should be modeled with a common base class, with a real "is-a" relationship, go that route. If ClassA and ClassB have nothing in common except those message, then inheritance is ...


1

What you expose depends highly on your application needs. One typically do dissociate users from contact informations allowing maximum flexibility. I'd recommend also to factorize the contact informations data into a single table. User (1,1) --- (0,1) Contact_Information Company (1,1) --- (0,1) Contact_Information Service Provider (1,1) --- (0,1) ...



Only top voted, non community-wiki answers of a minimum length are eligible