3 ms·

developer tooling is indeed not on the same level as other languages but don't say it does not exist https://www.pgadmin.org/docs/pgadmin3/1.22/debugger.html h

developer tooling is indeed not on the same level as other languages but don't say it does not exist https://www.pgadmin.org/docs/pgadmin3/1.22/debugger.html https://www.pgadmin.org/docs/pgadmin3/1.22/debugger.html logic that directly relates to the data being stored is much easier to express in the database (constraints), resulting in a big reduction of code which means small simple functions that almost don't need debugging. also what people call business logic often means fetching data from the db, processing it in some way and returning it. This is what views are for, they are definitions, so there's nothing to test there, except performance maybe.

vosper 9y ago
> logic that directly relates to the data being stored is much easier to express in the database (constraints), resulting in a big reduction of code which means small simple functions that almost don't need debugging. I think this is true for SQL experts (provided you're on the right database platform, of course - Postgres probably, MySQL and SQLite I doubt it) but it's not true for people with expertise in other language(s), which is the majority of people using the database. I can write arbitrarily complex business logic in Python and Javascript, which I am very familiar with. I would struggle to do that with SQL, and I know that all of my colleagues would struggle to understand what I had done. And I'm not unfamiliar with RDBMS - I've been working with them for years. Maybe that's a reflection on me, but I'd say it's been true of 95% of people I've ever worked with.
- ruslan_talpa 9y ago
  PostgreSQL vs Sqlie - sure, no argument there, i am talking about a reasonably complex thing like PG/Oracle/MsSql. Well, of course, it's easy to use what you already know as opposed to the thing you don't, and i agree that most of the people don't know the capabilities of the databases but your comment implied that it's a bad idea in general and i can't agree with that. The places where you would use SQL would be for reading data and some of them (views/queries) might get big, a bit complex but i doubt the equivalent code in any other language doing the same thing would be any simpler/easier to understand. I would bet the view code would be an order of magnitude shorter than the expression of the same problem in any other language, also you can use stored procedures (in any supported language) for reading. For writing ... you don't have to use Pl/pgSql ... use your beloved Python/Perl/JavaScript :) the only difference the code is running in your database.
ice109 9y ago
til there's a debugger in pgadmin3. will very much come in handy i'm sure. thanks. but i don't agree with this >also what people call business logic often means fetching data from the db, processing it in some way and returning it. This is what views are for, they are definitions, so there's nothing to test there, except performance maybe. i see business logic as things that connect disparate parts of the domain. not all of my business is in my db. a lot of it is somewhere else, in someone else's db, accessible only through their api. like i said in my op: unless you want to hack postgres (or whatever rdbms) into a full-fledged general use dev environment you're not going to be able to marshal all of these disparate resources.

vosper 9y ago

> logic that directly relates to the data being stored is much easier to express in the database (constraints), resulting in a big reduction of code which means small simple functions that almost don't need debugging. I think this is true for SQL experts (provided you're on the right database platform, of course - Postgres probably, MySQL and SQLite I doubt it) but it's not true for people with expertise in other language(s), which is the majority of people using the database. I can write arbitrarily complex business logic in Python and Javascript, which I am very familiar with. I would struggle to do that with SQL, and I know that all of my colleagues would struggle to understand what I had done. And I'm not unfamiliar with RDBMS - I've been working with them for years. Maybe that's a reflection on me, but I'd say it's been true of 95% of people I've ever worked with.

ruslan_talpa 9y ago
PostgreSQL vs Sqlie - sure, no argument there, i am talking about a reasonably complex thing like PG/Oracle/MsSql. Well, of course, it's easy to use what you already know as opposed to the thing you don't, and i agree that most of the people don't know the capabilities of the databases but your comment implied that it's a bad idea in general and i can't agree with that. The places where you would use SQL would be for reading data and some of them (views/queries) might get big, a bit complex but i doubt the equivalent code in any other language doing the same thing would be any simpler/easier to understand. I would bet the view code would be an order of magnitude shorter than the expression of the same problem in any other language, also you can use stored procedures (in any supported language) for reading. For writing ... you don't have to use Pl/pgSql ... use your beloved Python/Perl/JavaScript :) the only difference the code is running in your database.

ice109 9y ago

til there's a debugger in pgadmin3. will very much come in handy i'm sure. thanks. but i don't agree with this >also what people call business logic often means fetching data from the db, processing it in some way and returning it. This is what views are for, they are definitions, so there's nothing to test there, except performance maybe. i see business logic as things that connect disparate parts of the domain. not all of my business is in my db. a lot of it is somewhere else, in someone else's db, accessible only through their api. like i said in my op: unless you want to hack postgres (or whatever rdbms) into a full-fledged general use dev environment you're not going to be able to marshal all of these disparate resources.