3
This is a matter of personal preference, but nothing in the SQL standard imposes upper-case, and I find lower-case to be more legible
On your primary key columns, replace NOT NULL with an inline primary key constraint declaration which implies not null anyway
Move your foreign key constraints to inline
length_in_min could be a floating-point quantity, if you ...
3
There are a lot of things wrong with your code, but none of them should cause performance or security issues.
The main thing you are doing is you are using prepared statements. Of course, I would highly encourage you to make the switch to PDO as it is easier to use.
Some main pain points:
Never expose MySQL errors to the user! This is potentially a huge ...
3
Rather than passing the db connection into your constructor, I think it would be cleaner for your constructor to call a method in your DB class which first checks for an existing connection and only creates one if not found. This connection could be fetched by any other method if/when needed. It is best practice to create just one db connection and keep ...
2
Reserved keywords
Be careful with overly generic keywords, there is a good chance that they are reserved keywords.
Name, Open, Close are reserved keywords in MySQL.
Accordingly, I suggest that you you rename some objects from 'name' to for example: location_name, staff_name.
VARCHAR
VARCHAR (255) sounds like a default value suggested by a design tool. For an ...
1
Your -- TABLE Services comment is redundant and can be deleted, along with others of its kind
Your pseudo-inline syntax used to name your constraints is.. fine I guess? I don't usually place much importance on naming constraints, but this is one way to do it
You used to have on delete and on cascade clauses everywhere. That was the right thing to do, and ...
1
The way you implemented it looks absolute fine to me.
I would initialized the ObservabaleCollection with object creation and make it as get-only property:
public ObservableCollection<Person> People { get; } = new ObservableCollection<Person>();
That avoids the risk of null reference exceptions or different collection objects.
Clearing and ...
1
Add a Repository layer which would be between Data and Service layers. Never use Service directly to Data layer. The Service layer suppose to hold the business logic that would be applied on the Repository layer. Each Service can work with one or more repositories, but each repository should only work with one entity.
Here is an example :
public class ...
1
Some quick remarks:
PersonId (in Person) is IMHO not a great pattern. IMHO you shouldn't prefix a property name with its class name.
IDatabaseService is far to generic a name. I'd use PersonService and use that class to handle all Person-related queries. Then you can have more generic names like GetAll() instead of GetPeople().
Use descriptive names. ...
Only top voted, non community-wiki answers of a minimum length are eligible
