Rails seemingly handles it the same way as Laravel and it all makes sense very quickly.

The argument here that you would end up with 'addresss' is silly as you can also quickly handle that with a new inflection and it rarely even happens in practice.

Also, to be pedantic, rails handles this just fine by default: irb(main):001:0> "address".pluralize => "addresses"

I'd say Laravel handles this the same way as Rails as it was inspired by Rails. (nitpicking)

> Singular models, plural table names. Built in rules to pluralize, or override the defaults and add your own table name.

Why spend a single cycle of computing time on this? There's nothing objectively necessary about it, singular-only is entirely adequate to convey the important semantics. Every single symbol in any code devoted to this conversion unnecessary surface area / computation time that contributes nothing to the problem domain.

> I now understand that the author is referring to the relational algebra side of things here. I don't think that changes my skepticism of the argument though, because very rarely is it useful to discuss these things in terms of the mathemetics with your coworkers.

You don't even have to go that far. It's the user table. The order table. People know what an order is, and what a table in a database is; the semantics of db-table-ness conveys that it's a collection and the nature of the collection with so much more precision than english plurals that it's more likely obscuring to use those than contributing to understanding... much like a lot of natural language conventions, the emulation of which is really the only reason anybody does this.

But also, when we're talking about databases, relational algebra should no more be weird or inadmissible than boolean logic concepts are to coding.

Ecto gets this righter in my opinion. You always manually specify in your schema module. It's a trivial amount of work and in return you never have to worry about incorrect magic.

    defmodule User do
      use Ecto.Schema

      schema "users" do # table name
        field :name, :string
        field :age, :integer, default: 0
        field :password, :string, redact: true
        has_many :posts, Post
      end
    end

You'd usually generate a schema and matching migration with `mix phx.gen.schema Accounts.User users name:string ...`

Forcing users to specify manually means that you'll often end up with a mix of plural and singular names based on the whim of the developer who happens to implement that feature at that given time. I think that's strictly worse than Ruby or Laravel's automatic and predictable approach.

It will also be always clear, in ecto, what the table name is.

In rails if there is a table name prefix involved, you will have no idea

Yes, it won't be perfectly consistent. Just like variable names, module names, and everything else we name. But why does that matter?

Because in the long run its tiring to deal with inconsistencies, and when a framework can do it equally good or better than most devs and make it trivially simple to override it if you ever happen to need it, that must be better?

Aligning database theory and a modern RDBMS, you get:

1. Attribute => Column

2. Tuple => Row

3. Relation => Table

That's what he's talking about. I'm sure a debate about nomenclature will ensue.

For my part, this is not of any significance. I will store a tuple of data representing a user in a `users` table. If I'd stored it in a `user` table, then that wouldn't make my life hard either, but I'd prefer the plural to represent the fact that it's the name of a relation which has multiple tuples (each of which represents data for a singular user).

> I don't think so. We're naming the collection. The relation is the foreign key. that's why you would see `user_id`, not `users_id`.

that depends on your interpretation of "strictly speaking". As a (loose) implementation of the Relational Model[1], a table is indeed a Relation. In practical terms however - particularly with an ORM in play - a table stores a collection of entities, with relationships (not relations) implemented as foreign keys as you say.

> that's why you would see `user_id`, not `users_id`

Hmm, not really. Even in the relational interpretation, each row represents a single tuple in the relation. So singular phrasing for the attribute names is appropriate.

[1] https://en.wikipedia.org/wiki/Relational_model

Postgres convention is to have singular table names so that's violating those conventions (as well as a few more about column naming)

In mathematics, a relation is just a set of tuples. And that is exactly what a table is.

To go a bit further that equivalence is what put the relational in relational databases. Though really a set of tuples is just a model, you can reason about relations without needing to construct an explicit model for them (which is convenient when dealing with a relation on a proper class).

In practice, tables can be bags instead of sets.

Yes, that's true.

I don't disagree with any of your points. Personally, I even take it a step further by pluralizing both nouns in a "join table" name. For example, a model which joins a Group and a User will be named "GroupUser" and the table will be named "groups_users".

In my mind, the ORM object is a representation of a single group and a single user, so GroupUser. The table is a representation of all member users for all groups: groups_users. That goes against Rails conventions so I have to manually define the table name on such models but I also understand it's not exactly easy to detect these irregular inflections. I'll take the trade-off.