diff options
Diffstat (limited to 'readme.md')
-rw-r--r-- | readme.md | 53 |
1 files changed, 52 insertions, 1 deletions
@@ -64,13 +64,64 @@ of operations. For the same reason, the use of stored procedures was not | |||
64 | retained. | 64 | retained. |
65 | 65 | ||
66 | 66 | ||
67 | ## Project structure overview | 67 | ## Web application |
68 | |||
69 | ### Platform | ||
70 | |||
71 | #### Interface with the database | ||
72 | |||
73 | Object-Relational Mappers ([ORM]) such as [SQLAlchemy] are sometimes used to | ||
74 | partially or fully abstract the database and its entities behind objects in the | ||
75 | Object-Oriented Programming ([OOP]) sense. With those tools, it is possible to | ||
76 | generate tables, indexes, and constraints from annotated classes. They also | ||
77 | allow automatic querying and implicit joins to perform information retrieval, | ||
78 | and inserting and updating records in the database directly by setting fields | ||
79 | on linked objects. | ||
80 | |||
81 | [ORM]: https://en.wikipedia.org/wiki/Object-relational_mapping | ||
82 | [SQLAlchemy]: https://www.sqlalchemy.org/ | ||
83 | [OOP]: https://en.wikipedia.org/wiki/Object-oriented_programming | ||
84 | |||
85 | However, the [object-relational impedance mismatch problems][ORIM] often render | ||
86 | the use of ORMs impractical especially for complex queries, more often than not | ||
87 | resulting in the developers bypassing the ORM altogether. The tools also tend | ||
88 | to introduce performance issues due to the implicit queries they generate in | ||
89 | situations in which developers do not always expect them to. | ||
90 | |||
91 | [ORIM]: https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch | ||
92 | |||
93 | In the context of an database course aiming to teach SQL, such level of | ||
94 | abstraction is also a hindrance by itself. Therefore, the use of an ORM has | ||
95 | been excluded for this project. | ||
96 | |||
97 | More direct and less intricate forms of mappings, such as transparent result | ||
98 | tuples to Python immutable named tuples conversion, are preferred instead. | ||
99 | Features of this kind, which are directly provided by database drivers like | ||
100 | [psycopg], are often sufficient by themselves. | ||
101 | |||
102 | [psycopg]: https://www.psycopg.org/ | ||
103 | |||
104 | It remains desirable to segregate SQL queries into their own modules in order | ||
105 | to follow the Single-Responsibility Principle ([SRP]). Fortunately, libraries | ||
106 | such as [embrace] allow easily deriving Data Access Objects ([DAO]) from sets | ||
107 | of annotated raw SQL queries, exposing them as callable Python functions. | ||
108 | |||
109 | [SRP]: https://en.wikipedia.org/wiki/Single_responsibility_principle | ||
110 | [embrace]: https://pypi.org/project/embrace/ | ||
111 | [DAO]: https://en.wikipedia.org/wiki/Data_access_object | ||
112 | |||
113 | ### Project structure overview | ||
68 | 114 | ||
69 | * `./sql/` | 115 | * `./sql/` |
70 | * `tables.sql`: database initialisation statements | 116 | * `tables.sql`: database initialisation statements |
71 | * `queries.sql`: annotated SQL queries (from which the DAO is derived) | 117 | * `queries.sql`: annotated SQL queries (from which the DAO is derived) |
72 | * `./flake.nix`: project runtime and development environment description | 118 | * `./flake.nix`: project runtime and development environment description |
73 | 119 | ||
120 | ### Security considerations | ||
121 | |||
122 | * SQL injections are prevented by using proper query parameters substitution, | ||
123 | automatically handled by the embrace and psycopg libraries. | ||
124 | |||
74 | 125 | ||
75 | ## Development environment | 126 | ## Development environment |
76 | 127 | ||