Comment On Introducing the CSVDB

Yesterday, we learned about the latest programming paradigm, Vector Oriented Programming. Continuing that trend, I'd like to introduce the next big thing in data storage: the Column Separated Value DataBase. Discovered by Shaun, the CSVDB will do nothing short of revolutionizing the way we store, manage, and think about data ... [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Introducing the CSVDB

2006-03-30 14:49 • by CJ
This is the same technique we used in our databases assignment. The system works!

Re: Introducing the CSVDB

2006-03-30 14:52 • by RJ
Doesn't get much less worthless than this. [8-|]

Re: Introducing the CSVDB

2006-03-30 14:52 • by R.Flowers

To simplify the system, the first row will contain field names, NOT actual data.


To enhance the system, the row of field names will be repeated every 25 rows.


[;)]

Re: Introducing the CSVDB

2006-03-30 14:53 • by fat-tony
66455 in reply to 66453
Anonymous:
Doesn't get much less worthless than this. [8-|]


well, it could just be 1 column of csv :)

Re: Introducing the CSVDB

2006-03-30 14:53 • by loneprogrammer
Wow, you could implement pointers to other cells by storing it as "column,row,column!"

E.g. 12,5,8 would refer to the cell at column 8 in the same row where the value in column 12 equals 5!

Re: Introducing the CSVDB

2006-03-30 14:54 • by Disgruntled DBA
Great lords of stinking monkey fudge!  Someone got paid to create this?  Did he wipe afterwards, or at the very least wash his hands?

Re: Introducing the CSVDB

2006-03-30 14:54 • by Moo
In a company I first worked for some "specialist" in his field (Metallurgy) who happens to know C (A-Z in one function C) actually suggested we change away from a DB to a Excel sheets for our data storage.

Re: Introducing the CSVDB

2006-03-30 15:01 • by analysis
66459 in reply to 66458
The real WTF is why didn't they just go all the way and do...

create table data (
   table varchar(80) not null,
   column varchar(80) not null,
   id varchar(80) not null,
   data varchar(8000) null
)

Example usage to insert customer with id of 100:

insert into alldata values ('customer' , 'name' , '100' , 'john' )
insert into alldata values ('customer' , 'phone' , '100' , '555-1212' )
insert into alldata values ('customer' , 'address' , '100' , '123 main street' )

Re: Introducing the CSVDB

2006-03-30 15:02 • by DrCoracaodeManteiga

This is the right way to do it


CREATE TABLE [Table]
(
  [Column] text NULL
)


Simplicity above all!

Re: Introducing the CSVDB

2006-03-30 15:03 • by anon
About the best I can say about this is at least they used VARCHAR instead of CHAR!

Re: Introducing the CSVDB

2006-03-30 15:04 • by John Hensley
We're going to need some better goggles.



Re: Introducing the CSVDB

2006-03-30 15:04 • by marvin_rabbit
Alex Papadimoulis:

... and yes, you saw right. The CSVDB, unlike CSV files, allows you to have comma-separated data within a cell of column-separated data.


Don't be rediculous.  You're not supposed to store CSV in the fields...  That's supposed to be XML data.

Sheesh.

Re: Introducing the CSVDB

2006-03-30 15:06 • by Moo
66465 in reply to 66464
I dont know about you but I store my persistent data on our conference room projector.  It is high resoluton so I think I can cram lots of data in there.

Re: Introducing the CSVDB

2006-03-30 15:07 • by rob_squared
66466 in reply to 66456
loneprogrammer:
Wow, you could implement pointers to other cells by storing it as "column,row,column!"

E.g. 12,5,8 would refer to the cell at column 8 in the same row where the value in column 12 equals 5!



That is only implemented in ECSVDB, the E is for Enterprise!

Re: Introducing the CSVDB

2006-03-30 15:15 • by benvenista
66469 in reply to 66464

it's amazing the lengths some people go to to make a relational database non-relational. But this design is lacking in vision... what they really need to do is have a single table called database:


create table database (tableName varchar(255), tableData text)


Then each field could represent a table with rows delimited by tildas (~) and columns delimited by pipes (|)


Think of the simplicity - an entire database stored in a single table.


Insert into database(tableName, tableData) values ('customers', 'fred|jones|1')


update database set tableData = 'fred|jones|1~amy|jackson|2' where tableName = 'customers'


Then you could write some really clever and convoluted string manipulation functions to query data and join 'tables'.


 

Re: Introducing the CSVDB

2006-03-30 15:17 • by LOLLORCOASTER
66470 in reply to 66465
Anonymous:
I dont know about you but I store my persistent data on our conference room projector.  It is high resoluton so I think I can cram lots of data in there.

Oh that's silly.  We have "offshored" all our data storage needs.  Now whenever any data is needed we call up a special residential warehouse (a data warehouse, heh) built to house and feed the workers, otherwise known as "Memorizers".  Then we either ask them to recall some data or we give them some data to memorize.  I cannot even describe the savings we realized from not having to buy any hardware or software, and it's so scalable!!!  And our users love it, because they don't have to use any complicated query languages (though some practice in accent decoding is necessary).

Re: Introducing the CSVDB

2006-03-30 15:18 • by Sean
I have a feeling the designer of this database used to be a vector-oriented programmer.  It's kinda neat to follow someone's career path through the WTFs he leaves behind.

Re: Introducing the CSVDB

2006-03-30 15:18 • by Digitalbath
66472 in reply to 66465

Anonymous:
I dont know about you but I store my persistent data on our conference room projector.  It is high resoluton so I think I can cram lots of data in there.


Hahahaha....that's funny.  Make sure you have plenty of "backup" in the form of light bulbs. :)

Re: Introducing the CSVDB

2006-03-30 15:19 • by ferrengi
This looks like it is a lot more complicated and difficult to maintain than the Vector Oriented Programming stuff.
Also, once you get beyond something like 1000 rows the system will likely grind to halt.

I stopped long ago trying to figure out why people do this sort of stupidity but it so happens that I've come up with a theory on this.
I guess one of the requirements for this project was to use a database. I can just imagine the programmer saying to himself, "They think they can twist my arm into using a stinkin database instead of Excel spreadsheets or CSV? I show em! I don't have to waste my valuable time learning a new technology if I don't want to!"

This way he gets away with not having to know databases and then as soon as he leaves the company he can laugh at the poor soul that inherits this mess. Isn't life great?

Re: Introducing the CSVDB

2006-03-30 15:22 • by temp
Minor quibble. The CSV format does allow for comma seperated data within a field. That field, however, must be surrounded by double quotes. Double quotes inside of such a field must be escaped using another double quotes character.

Re: Introducing the CSVDB

2006-03-30 15:26 • by Djinn
Even in my earliest days I wouldn't have thought that was even remotly a good idea. That's one of the worst WTFs ever. I'd just suggest starting over on that project.

Re: Introducing the CSVDB

2006-03-30 15:30 • by Alun Jones
66479 in reply to 66472
Digitalbath:

Anonymous:
I dont know about you but I store my persistent data on our conference room projector.  It is high resoluton so I think I can cram lots of data in there.


Hahahaha....that's funny.  Make sure you have plenty of "backup" in the form of light bulbs. :)



Strangely enough, some of the early computer "memory" was a CRT with a sensor array in front of it as a cheesy "delay line".

Re: Introducing the CSVDB

2006-03-30 15:30 • by Yeah, what the fag
Alex Papadimoulis:

... and yes, you saw right. The CSVDB, unlike CSV files, allows you to have comma-separated data within a cell of column-separated data.



Actually, the format is less bloated and easier processable than the modern idiot programmer's favorite toy-format, the Xtremely Moronic Language.

Re: Introducing the CSVDB

2006-03-30 15:31 • by Volmarias
66482 in reply to 66477
I propose the following solution to programmers who write things like this:

Euthanasia

Re: Introducing the CSVDB

2006-03-30 15:32 • by pinguis
Why does this remind of the Flat File Society does relational databases??
Maybe they ARE a real society after all, and exist scattered around the world mining our software for some grim agenda.
Anyway I feel sorry already for those among us that will say "The real WTF is..." an somehow try to defend this

Re: Introducing the CSVDB

2006-03-30 15:32 • by maht
66484 in reply to 66474
Anonymous:
Minor quibble. The CSV format does allow for comma seperated data within a field. That field, however, must be surrounded by double quotes. Double quotes inside of such a field must be escaped using another double quotes character.



that's not trying =)

Name the popular RDBMS this *sample* code is in the documentation of :

SELECT f1[1][-2][3] as e1, f1[1][-1][5] AS e2 FROM (SELECT '[1:1][-2:-1][3:5]={{{1,2,3},{4,5,6}}}'::int[] AS f1) AS ss;

e1 | e2
----+----
1   |  6
(1 row)


Re: Introducing the CSVDB

2006-03-30 15:33 • by Michael K. Campbell
Good hell... trying to create a table with:
  [Col001] VARCHAR(8000) NULL,
[Col002] VARCHAR(8000) NULL,
[Col003] VARCHAR(8000) NULL,

In SQL Server (which it looks like they're using) will throw warnings, as 8k is effectively the max page size for a single row, meaning that you can't have > varchar(8060) in a single table.
So these guys had to REALLY work hard at this - in the sense that every table they created displayed a little red message that said: hey, you're a moron, this won't work.

Let alone how useless this data would be..

Idiots.


Re: Introducing the CSVDB

2006-03-30 15:34 • by nobody
66486 in reply to 66474
> Minor quibble. The CSV format does allow for
> comma seperated data within a field. That field,
> however, must be surrounded by double quotes.
> Double quotes inside of such a field must be
> escaped using another double quotes character.

You're kidding, right?

Re: Introducing the CSVDB

2006-03-30 15:36 • by lizardfoot
66487 in reply to 66470
Anonymous:
Anonymous:
I dont know about you but I store my persistent data on our conference room projector.  It is high resoluton so I think I can cram lots of data in there.

Oh that's silly.  We have "offshored" all our data storage needs.  Now whenever any data is needed we call up a special residential warehouse (a data warehouse, heh) built to house and feed the workers, otherwise known as "Memorizers".  Then we either ask them to recall some data or we give them some data to memorize.  I cannot even describe the savings we realized from not having to buy any hardware or software, and it's so scalable!!!  And our users love it, because they don't have to use any complicated query languages (though some practice in accent decoding is necessary).


That's silly.  We give all our data to the gods of fire.  When we want to retrieve data, we sacrifice an intern.  It gets a little messy sometimes, but we save tons on heating in the winter.


Re: Introducing the CSVDB

2006-03-30 15:37 • by bullseye

O...M...G...


Surely this was just someone's malicious attempt to purposefully destroy the usefulness of all the technology they had available?


If not, I can take comfort in the fact that this site makes me feel like a genius every 24 hours.

Re: Introducing the CSVDB

2006-03-30 15:37 • by say what
In Gods name, why? It's not as if the person that wrote this was unaware of the existence of databases.

This looks as if some moron has decided to waste some elses money on a pet experiment.

Re: Introducing the CSVDB

2006-03-30 15:39 • by xcor057

The forum should stop protecting the identity of these perpetrators.  Instead, those posting and reporting these incidents should be required to hack into the company’s security badge image database and post them with the WTF.


 


Then make use of The Daily WTF’s Most Wanted posters during the interview process.

Re: Introducing the CSVDB

2006-03-30 15:45 • by bullseye
66492 in reply to 66490

Anonymous:
Then make use of The Daily WTF’s Most Wanted posters during the interview process.


Wouldn't it be great if we could trick these people into thinking that it is some badge of honor to get "noticed" here.


Interviewer: Have you ever had any code or articles published?
Interviewee: Yes!  Several times on the Internet. Here are some links to the Daily WTF.
Interviewer: ...

Re: Introducing the CSVDB

2006-03-30 15:45 • by R.Flowers
66493 in reply to 66479

Anonymous:


Strangely enough, some of the early computer "memory" was a CRT with a sensor array in front of it as a cheesy "delay line".


It's a fascinating subject. Some early computers (UNIVAC era or there-abouts) used a mercury delay line memory, where a pulse induced in one end of a mercury-filled tube would travel through the tube to be read on the other end in the next cycle.


http://en.wikipedia.org/wiki/Delay_line_memory

Re: Introducing the CSVDB

2006-03-30 15:46 • by whalemangler
66494 in reply to 66490
Good lord.  Actually USING csv files would be better than that.

Re: Introducing the CSVDB

2006-03-30 15:46 • by Runtime Error
Finally someone has found the perfect datastore to pair with Ruby On
Rails.  None of those messy domain models to keep track of. 
This is the future folks.

Re: Introducing the CSVDB

2006-03-30 15:47 • by MB
66496 in reply to 66480
Anonymous:
Alex Papadimoulis:

... and yes, you saw right. The CSVDB, unlike CSV files, allows you to have comma-separated data within a cell of column-separated data.



Actually, the format is less bloated and easier processable than the modern idiot programmer's favorite toy-format, the Xtremely Moronic Language.


Sure - just as long as sender and receiver agree on line endings, quoted forms, column headers, datatypes, and do some fancy footwork on master detail relationships - CSV will do you just fine.
OTOH, if you'd rather the data come with that description, or have a schema you can validate against, or write queries against the data without importing it into a database, etc. - then XML is probably the better choice.

Re: Introducing the CSVDB

2006-03-30 15:47 • by dhromed
66497 in reply to 66484
Anonymous:
Anonymous:
Minor quibble. The CSV format does allow for comma seperated data within a field. That field, however, must be surrounded by double quotes. Double quotes inside of such a field must be escaped using another double quotes character.



that's not trying =)

Name the popular RDBMS this *sample* code is in the documentation of :

SELECT f1[1][-2][3] as e1, f1[1][-1][5] AS e2 FROM (SELECT '[1:1][-2:-1][3:5]={{{1,2,3},{4,5,6}}}'::int[] AS f1) AS ss;

e1 | e2
----+----
1   |  6
(1 row)



We're not talking about Regular Expressions

Wait.

Re: Introducing the CSVDB

2006-03-30 15:48 • by Runtime Error
66498 in reply to 66492
bullseye:

Anonymous:
Then make use of The Daily WTF’s Most Wanted posters during the interview process.


Wouldn't it be great if we could trick these people into thinking that it is some badge of honor to get "noticed" here.


Interviewer: Have you ever had any code or articles published?
Interviewee: Yes!  Several times on the Internet. Here are some links to the Daily WTF.
Interviewer: ...





Couldn't we just track these people down and brand "WTF" on their foreheads. 

Re: Introducing the CSVDB

2006-03-30 15:55 • by maht
66500 in reply to 66496
Anonymous:
... then XML is probably the better choice.


may I ask which other schemes you considered before making this decision ?

CSV is not a "standard" anywhere so it is a poor choice for unambiguous data transmission.

in XML

<row><cell>cell1</cell></row>
and
<row>
    <cell>
          cell1
    </cell>
</row>

are *not* the same

I hoped that worked out, XML makes it hard to post examples, another reason to stand idly by not calling 911 when it looks like it might die !!


Re: Introducing the CSVDB

2006-03-30 15:58 • by Adam
66503 in reply to 66470
Anonymous:
Anonymous:
I dont know about you but I store my persistent data on our conference room projector.  It is high resoluton so I think I can cram lots of data in there.

Oh that's silly.  We have "offshored" all our data storage needs.  Now whenever any data is needed we call up a special residential warehouse (a data warehouse, heh) built to house and feed the workers, otherwise known as "Memorizers".  Then we either ask them to recall some data or we give them some data to memorize.  I cannot even describe the savings we realized from not having to buy any hardware or software, and it's so scalable!!!  And our users love it, because they don't have to use any complicated query languages (though some practice in accent decoding is necessary).


Yeah, just make sure to send your data out to multiple memorizers for redundancy purposes.

Personally, I implemented a Raid 0 with it. Each memorizer gets three sentances. That makes it easier for them to remember. Query process doesn't speed up any though, despite what those stupid consultants said.

Re: Introducing the CSVDB

2006-03-30 16:02 • by Noam Samuel
This is a sentence in a comment to a message ridiculing a cryptic database format. This is the second sentence in a comment to a message ridiculing a cryptic database format. This is the third sentence in a comment to a message ridiculing a cryptic database format. This is the fourth sentence in a comment to a message ridiculing a cryptic database format. This is the fifth sentence in a comment to a message ridiculing a cryptic database format. This is the sixth sentence in a comment to a message ridiculing a cryptic database format.

This is a sentence in the second paragraph of a comment to a message ridiculing a cryptic database format. This is the second sentence in the second paragraph of a comment to a message ridiculing a cryptic database format. This is the third sentence in the second paragraph of a comment to a message ridiculing a cryptic database format. This is the fourth sentence in the second paragraph of a comment to a message ridiculing a cryptic database format. This is the fifth sentence in the second paragraph of a comment to a message ridiculing a cryptic database format. This is the sixth sentence in the second paragraph of a comment to a message ridiculing a cryptic database format.

Re: Introducing the CSVDB

2006-03-30 16:03 • by neek
Paula coded it? It's brillant!

Re: Introducing the CSVDB

2006-03-30 16:04 • by WTF Batman
66507 in reply to 66484
Anonymous:

Name the popular RDBMS this *sample* code is in the documentation of :

SELECT f1[1][-2][3] as e1, f1[1][-1][5] AS e2 FROM (SELECT '[1:1][-2:-1][3:5]={{{1,2,3},{4,5,6}}}'::int[] AS f1) AS ss;

e1 | e2
----+----
1   |  6
(1 row)



Hmm. That reminds me of PostgreSQL.

Re: Introducing the CSVDB

2006-03-30 16:07 • by maht
66508 in reply to 66507
WTF Batman:


Hmm. That reminds me of PostgreSQL.



Holy religious wars, wtfman, you win

Re: Introducing the CSVDB

2006-03-30 16:09 • by e.thermal
66509 in reply to 66482

Volmarias:
I propose the following solution to programmers who write things like this: Euthanasia


What do the Youth in Asia have to do with this?

Re: Introducing the CSVDB

2006-03-30 16:12 • by Anonymous Coward
Sometimes this site hits a little too close to home... I'm taking a quick sanity break from fixing all the code that the other people wrote on the project and the WTF for today is THE EXACT PROBLEM I'M TAKING A SANITY BREAK FROM! ARG!!!!!!<:o)

for the love of pete...


Re: Introducing the CSVDB

2006-03-30 16:16 • by jackass
That is true geniusenessness

Re: Introducing the CSVDB

2006-03-30 16:20 • by WTF Batman
66513 in reply to 66508
Anonymous:

Holy religious wars, wtfman, you win


Thought so. I've actually been playing with Postgres recently. I'm finding it to be an incredible database. However, some of the syntax can be a little... well... obfuscated. So far, I'd say that's the exception rather than the rule, but you sure found a real gem.

Re: Introducing the CSVDB

2006-03-30 16:21 • by Scott S. McCoy
66515 in reply to 66458
Anonymous:
In a company I first worked for some
"specialist" in his field (Metallurgy) who happens to know C (A-Z in
one function C) actually suggested we change away from a DB to a Excel
sheets for our data storage.




I'll have to try that some day!  Brilliant!

« PrevPage 1 | Page 2 | Page 3Next »

Add Comment