247 reputation
28
bio website
location Netherlands
age 23
visits member for 2 years, 5 months
seen Jan 15 at 10:01

Jul
2
awarded  Curious
Jun
8
awarded  Popular Question
Sep
25
accepted Migrating database live while being severely handicapped
Sep
23
comment Migrating database live while being severely handicapped
I just realized I misread you're answer. I thought you suggested to use views on the old schema. Using views on a new schema makes a lot of sense! Thanks!
Sep
23
awarded  Commentator
Sep
23
comment Migrating database live while being severely handicapped
I do already use views a lot, but views don't improve performance since they're merely stored queries. Therefore I need to do something else to solve these performance issues. Also, replication will only be one way (old->new), so I guess that makes the operation a little bit easier. I won't change the inserts and updates because these don't have performance issues and also because a lot of these are hidden and accessible due to abstractions from the CMS.
Sep
23
comment Migrating database live while being severely handicapped
The query editor simply analyses the query before executing. Whenever I access a table without a certain prefix, it complains. Also, the entire stack is going to be replaced, so in a few months time I won't have to use the CMS anymore:)
Sep
23
asked Migrating database live while being severely handicapped
Jun
14
comment Best practice for storing record metadata
Thanks, this was a way better answer than I expected!
Jun
12
comment Best practice for storing record metadata
@a_horse_with_no_name - Right now I only need creation time, update time and creation source. The fields are fixed so I don't need key-value like storage. I'm only worried about where I should store the data.
Jun
12
asked Best practice for storing record metadata
Jun
5
awarded  Yearling
Jun
5
comment Postgresql constrains on FK
I introduced the Student_Education table since many fields are common to each of the <type>Education tables. However, I just realize that I could also use inheritance to make sure each of the <type>Education tables would have those columns, without having to specify them more than once. Dropping the Student_Education table certainly makes things a lot simpler. I think I prefer your second solution most, it makes a lot of sense to create different tables for each education type. Thanks for your advice!
Jun
4
comment Postgresql constrains on FK
I think this is the best solution so far, even though this is still not an ideal solution. Nullable columns is not an option because it simply does not solve the problem at all. This part of the database has to be done right, it is a crucial part of the application and inconsistencies are not acceptable here. Another option might be to use triggers, but I'm not sure yet which of these 2 options I like best. Anyway, thanks for your help!
Jun
4
comment Postgresql constrains on FK
This is exactly the situation I try to avoid. If I add all the details to the Student_Education table I will have quite a lot of unused columns for each row. Also, this still doesn't solve the problem at all: it is still possible to add rows which uses the details columns for type X and references to an education of type Y. Moreover, moving all detail columns to the Student_Education table makes it impossible to create NOT NULL details columns.
Jun
4
comment Postgresql constrains on FK
@ypercube - But that still doesn't add the correct constraints on the <type>Education tables, does it? E.g. it would still be possible to create row in MasterEducation which references a row in Student_Education whose type is bachelor. I try to achieve a FK like ('master', EducationID) REFERENCES Education (EducationType, EducationID). Unfortunately such a foreign key does not work.
Jun
4
asked Postgresql constrains on FK
Mar
28
comment Postgres: Use result of group by as column names
Thanks for your answer! Unfortunately I can't install the tablefunc module and thus I had to go with the solution provided by bluefeet.
Mar
28
comment Postgres: Use result of group by as column names
Unfortunately I can't install the tablefunc module, but your other solution works for me. Thanks!
Mar
28
accepted Postgres: Use result of group by as column names