If this is difficult, you probably didn't normalize your database.Īlso, in an object-relational DBMS, you can have type definitions independent of table definitions. As is often necessary, when requirements change, you can always create a VIEW in the DB to mimic the previous table structure. If the database is well normalized, various ways of filtering and combining the entities are really part of the View, and the DB stores the Model. While you are correct that is often better to put an abstraction layer between the UI and the storage layer, not all application designs require it. Oh, and fearless_fool, I don't know if any other systems have this, but Informix has a RESTful API directly to the database entities. But, I would not fight it if I walked into a system of the latter. It is not even true if data are partitioned/sharded across tablespaces or server instances. My preference is for the former, because the fact that instances of the same type are stored in the same physical location is only a detail of how most servers are implemented.
Conceptualized this way, queries can be paraphrased, "server, for objects stored in this location, do the following." This creates a collection of people that effectively have the same, unnamed data structure. Essentially, the queries in the set language SQL can be paraphrased as "server, for the objects of this type, do the following."
This makes SQL more readable for WHERE clauses and joins, regardless of how many instances are being joined or filtered. The CREATE statement defines a data structure of which multiple instances can be created. The former leads to singular names and the latter leads to plural names. It can also be considered a collection of objects. They are there for different reasons.Ī table can be conceptualized as a data structure or relationship, a type definition. And when you look at it that way, there's no conflict between pluralized API entity names and singular SQL entity names. For other than a throw-away experiment, I would suggest spending some time determining the higher-level operations the API should represent. So if you are using an API as just an interface straight into a database, pluralization is the least of your worries. Use an API to narrow the client down to just valid operations. especially clients you do not have developmental control over. The system stagnates and is eventually replaced.ĭon't expose your database structure directly to clients.All but trivial changes become increasingly risky and time-consuming.
Elixir ecto table names plural or singular code#
The code base gradually becomes harder to understand due to fragmentation, confusing names, and left-over baggage which can't be removed safely.New features can't change existing data structures, so its data and functionality is often artificially separated even when it holistically belongs with an existing feature.Even when they are named incorrectly for their function or are no longer used. You cannot rename or remove existing tables/columns.because your clients depend on your database structure.īased on my experience with this scenario: How are you going to setup a user permission to allow the merge feature while not allowing user deletion? Is deleting a user even fairly represented by DELETE /users/1 when /usersettings also exists?ĪPI operations should be looked at as higher-(than-database)-level operations which may cause multiple changes in the system. Let's say you need to merge two user accounts. Securing the API becomes a black hole of despair DBAs may recognize this as a stored procedure, but the API operation may have effects beyond just the database. These data operations are often easier to sequence on the server side, while being initiated from the client as a single operation. POST /usersettings with some default valuesīut how do you handle a failure of step #2? How many times is this same handling logic copy-pasta'd to other clients of your API?.
I imagine the steps to create a new user documented as something like this: (not an exhaustive list) It makes integrating with the API difficult This has some pretty terrible effects on the API. The principal reason this is bad? The code describing "how does this operation affect my data?" becomes client code. We can find this described as an anti-pattern at least as far back to 2009. So the issue to unpack here is the conceptual understanding that an API maps directly to the database. The SQL conventions mentioned (whether you want to use them or not) were not designed with API access in mind. It is trying to bring standardization to API access. The REST spec (whatever level you want to go with) wasn't designed as database access.
0 kommentar(er)
