2 ms·

It's extraordinary how often I have to point out that what someone is proposing is either called a "database" (to people who think it's a good idea to build a c

It's extraordinary how often I have to point out that what someone is proposing is either called a "database" (to people who think it's a good idea to build a complicated file system complete with various metadata files) or a "programming language" (to the people who think it would be helpful to have some language which can logically encode business rules in a computationally understandable manner).

kbenson 10y ago
The interesting thing is that it goes both ways. Sometimes, when someone wants to store blobs of data in the database, you need to explain to them that it's probably better to use the file system in some manner. The common refrain is "no, we want to use the database", to which the answer often is "the file system is a database, just one that's already been optimized for what you are trying to do". Similarly, sometimes it's useful to provide just enough primitives that a "non-programmer" can be trained on how to perform a very constrained set of operations on the data they deal with, and provide them with a simplistic language that funnels them into the types of operations they are most likely to want and away from (or disallowing) operations that are deemed problematic or complex. The issue is that these options are usually not what you want to do. Not because they are wrong, but because they are much more likely to result in something worse, given the possible outcomes. Usually, the result is multiple of the following: too late, too slow, too complex, too inefficient, too hard to maintain, too hard to develop. That said, given a fairly lax timetable, smart people to design and develop the system with, and a clear vision of what needs to be accomplished, great things can be accomplished. But how often to do we get all that at once?

2 ms·

It's extraordinary how often I have to point out that what someone is proposing is either called a "database" (to people who think it's a good idea to build a c

by morgante 10y ago

kbenson 10y ago
The interesting thing is that it goes both ways. Sometimes, when someone wants to store blobs of data in the database, you need to explain to them that it's probably better to use the file system in some manner. The common refrain is "no, we want to use the database", to which the answer often is "the file system is a database, just one that's already been optimized for what you are trying to do". Similarly, sometimes it's useful to provide just enough primitives that a "non-programmer" can be trained on how to perform a very constrained set of operations on the data they deal with, and provide them with a simplistic language that funnels them into the types of operations they are most likely to want and away from (or disallowing) operations that are deemed problematic or complex. The issue is that these options are usually not what you want to do. Not because they are wrong, but because they are much more likely to result in something worse, given the possible outcomes. Usually, the result is multiple of the following: too late, too slow, too complex, too inefficient, too hard to maintain, too hard to develop. That said, given a fairly lax timetable, smart people to design and develop the system with, and a clear vision of what needs to be accomplished, great things can be accomplished. But how often to do we get all that at once?