I've been using PostgreSQL arrays to store group members and administrators in a Rails Project.
So my table looked like this:
Column | Type
-------------+-----------------------------
id | bigint
name | character varying
members | character varying[]
admins | character varying[]
description | text
created_at | timestamp without time zone
But recently I switched to ActiveRecord many-to-many associations, because it made the code easier to read and because everyone else does it.
But which solution is better in terms of performance? Are the PostgreSQL Arrays be faster because they don't need another table or am I missing something?
Related
I need to create a Rails app that will show/utilize our current CRM system data. The thing is - I could just take Rails and use current DB as backend, but the table names and column names are the exact opposite Rails use.
Table names:
+-------------+----------------+--------------+
| Resource | Expected table | Actual table |
+-------------+----------------+--------------+
| Invoice | invoices | Invoice |
| InvoiceItem | invoice_items | InvItem |
+-------------+----------------+--------------+
Column names:
+-------------+-----------------+---------------+
| Property | Expected column | Actual column |
+-------------+-----------------+---------------+
| ID | id | IniId |
| Invoice ID | invoice_id | IniInvId |
+-------------+-----------------+---------------+
I figured I could use Views to:
Normalize all table names
Normalize all column names
Make it possible to not use column aliases
Make it possible to use scaffolding
But there's a big but:
Doing it on a database level, Rails will probably not be able to build SQL properly
App will probably be read-only, unless I don't use Views and create a different DB instead and sync them eventually
Those disadvantages are probably even worse when you compare it to just plain aliasing.
And so I ask - is Rails able to somehow transparently know the id column is in fact id, but is InvId in the database and vice versa? I'm talking about complete abstraction - simple aliases just don't cut it when using joins etc. as you still need to use the actual DB name.
When I try to join on one of the customDimensions fields, I get a syntax error: "join attributes may be only column entity or equality expressions". I am able to join on non-custom columns such as name or timestamp.
Sample code:
let ExperimentLaunchedEvents = customEvents | where name=="ExperimentLaunched" and timestamp > now(-30d);
let ExperimentTerminatedEvents = customEvents | where name=="ExperimentTerminated" and timestamp > now(-30d);
ExperimentLaunchedEvents
| project name, timestamp, experimentId=customDimensions.ExperimentId
| join kind=leftanti (ExperimentTerminatedEvents
| project name, timestamp, experimentId=customDimensions.ExperimentId) on tostring(experimentId)
If joining on customDimensions columns is not supported, is there any way to achieve selecting launched experiments that haven't been terminated? Thanks!
As mentioned by John in the comments When using custom dimensions for any operations you need to convert it to a type that can be used by the query engine. In this case I use tostring(), but you can also use other functions like toint().
I also extend a column type so it can be reused in clauses like join or where without having to use the long hand over and over again.
ExperimentLaunchedEvents
| extend experimentId=tostring(customDimensions.ExperimentId)
| project name, timestamp, experimentId
| join kind=leftanti (ExperimentTerminatedEvents
| extend experimentId=tostring(customDimensions.ExperimentId)
| project name, timestamp, experimentId)
on experimentId
Same as James Davis answer, but a minor enhancement of stopping the experimentId column repeating twice due to its inclusion in both the project clauses, as pointed out by squallsv
let myExperimentLauncedEvents=
ExperimentLaunchedEvents
| extend experimentId=tostring(customDimensions.ExperimentId)
| project name, timestamp, experimentId
| join kind=leftanti (ExperimentTerminatedEvents
| extend experimentId=tostring(customDimensions.ExperimentId)
| project name, timestamp, experimentId)
on experimentId;
myExperimentLauncedEvents
| project name, timestamp, experimentId
As a result, by assigning the result to a variable (temp table), and then using the project clause on that variable, we can choose to display only those columns that are required.
So I have been out of the coding game for a while and recently decided to pick up rails. I have a question about the concept of Join tables in rails. Specifically:
1) why are these join tables needed in the database?
2) Why can't I just JOIN two tables on the fly like we do in SQL?
A join table allows a clean linking of association between two independent tables. Join tables reduce data duplication while making it easy to find relationships in your data later on.
E.g. if you compare a table called users:
| id | name |
-----------------
| 1 | Sara |
| 2 | John |
| 3 | Anthony |
with a table called languages:
| id| title |
----------------
| 1 | English |
| 2 | French |
| 3 | German |
| 4 | Spanish |
You can see that both truly exist as separate concepts from one another. Neither is subordinate to the other the way a single user may have many orders, (where each order row might store a unique foreign_key representing the user_id of the user that made it).
When a language can have many users, and a user can have many languages -- we need a way to join them.
We can do that by creating a join table, such as user_languages, to store every link between a user and the language(s) that they may speak. With each row containing every matchup between the pairs:
| id | user_id | language_id |
------------------------------
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 1 | 4 |
| 4 | 2 | 1 |
| 5 | 3 | 1 |
With this data we can see that Sara (user_id: 1) is trilingual, while John(user_id: 2) and Anthony(user_id: 3) only speak English.
By creating a join table in-between both tables to store the linkage, we preserve our ability to make powerful queries in relation to data on other tables. For example, with a join table separating users and languages it would now be easy to find every User that speaks English or Spanish or both.
But where join tables get even more powerful is when you add new tables. If in the future we wanted to link languages to a new table called schools, we could simply create a new join table called school_languages. Even better, we can add this join table without needing to make any changes to the languages SQL table itself.
As Rails models, the data relationship between these tables would look like this:
User --> user_languages <-- Language --> school_languages <-- School
By default every school and user would be linked to Language using the same language_id(s)
This is powerful. Because with two join tables (user_languages & school_languages) now referencing the same unique language_id, it will now be easy to write queries about how either relates. For example we could find all schools who speak the language(s) of a user, or find all users who speak the language(s) of a school. As our tables expand, we can ride the joins to find relations about pretty much anything in our data.
tl;dr: Join tables preserve relations between separate concepts, making it easy to make powerful relational queries as you add new tables.
I am using Ruby on Rails 4 and MySQL. I have three types. One is Biology, one is Chemistry, and another is Physics. Each type has unique fields. So I created three tables in database, each with unique column names. However, the unique column names may not be known before hand. It will be required for the user to create the column names associated with each type. I don't want to create a serialized hash, because that can become messy. I notice some other systems enable users to create user-defined columns named like column1, column2, etc.
How can I achieve these custom columns in Ruby on Rails and MySQL and still maintain all the ActiveRecord capabilities, e.g. validation, etc?
Well you don't have much options, your best solution is using NO SQL database (at least for those classes).
Lets see how can you work around using SQL. You can have a base Course model with a has_many :attributes association. In which a attribute is just a combination of a key and a value.
# attributes table
| id | key | value |
| 10 | "column1" | "value" |
| 11 | "column1" | "value" |
| 12 | "column1" | "value" |
Its going to be difficult to determin datatypes and queries covering multiple attributes at the same time.
Ruby on Rails ORM(object relational mapping) has a thing call polymorphic associations that allow a foreign key to be used to reference 2 or more other tables. This is achieved by creating an additional column called "type" that specifies the table with which the foreign key is associated with.
Does this implementation have a name from a database point of view? and is it good/bad practice?
thanks
Yes, using multiple keys to reference a unique record is known as a composite key. Whether it's good or bad practice is dependant on your database schema.
Example Scenario
Let's pretend that we have 4 tables: A, B, C and Z. Z maintains a reference to A, B, and C. Each record contains a reference to a single table. Below is two potential schema's for Z.
Single Foreign Key
We need a column to store the reference for each of the tables. That means we'll end up with NULL values for the unused columns. In future, if we introduce a D table, then we'll be required to add a new column to Z.
id | a_id | b_id | c_id
-----------------------
1 | 1 | NULL | NULL
2 | NULL | 1 | NULL
3 | NULL | NULL | 1
Composite Foreign Key
We start off with two columns for building a reference to the other tables. However, when we introduce D we do not need to modify the schema. In addition, we'll never have columns with NULL values.
id | z_id | z_type
------------------
1 | 1 | 'A'
2 | 1 | 'B'
3 | 1 | 'C'
Therefore, we can achieve some level of normalisation by using composite foreign keys. Provided that both columns are indexed, querying should be very fast. While it must be slower than using a single foreign key, the difference is insignificant.
Often it's tempting to use Rails' polymorphic associations whenever you have data that appears to be the same (Eg: Address). You should always exercise caution when coupling many models together. A good indicator you've gone too far is when you notice yourself switching based on the association type. A potential solution is to refactor common code out into a module and mix that into the models you care about instead.
Not all databases allow a composite foreign key and personally I'd shoot anyone who tried to do that to my database. Foreign keys MUST be maintained by the datbase not somethign like Rails. There are other processes which typically hit a database where this critical relationship must be checked which may not use an ORM (I certainly wouldn't use such a thing to import a 10,000, 000 record file or update a million price records or fix a data integrity problem.