you dont need a table, fuckwit. This is NOT RELATIONAL DATA. IT IS COLUMNAR DATA. Please can someone save me from this moron?
Database organization
- Thread starter cjbuckley4
- Start date
I have not found time yet. Give me till the end of the upcoming weekend. Sorry for the delay.
its on each option exchange site, a simple google search should suffice. Yes, there are clear rules as function of absolute dollar amount of traded underlying and also number of strikes among couple other metrics.
retard, tables are not ONLY found in RDBMS, you clueless fuckwit
Column data as a group are the TABLES you retard,
god, you are not only a liar, a psycho, and a fairy tale artist but also an angry troll living in his mom basement
Facts ? don't confuse your insults and your mental projections with facts, fraud. You have already been exposed as a fraud in that other thread, claiming to know programming and then later acknowledging you never wrote a single line of code, professionally or otherwise.
My little clueless friend, when it comes to manipulating large datasets, APIs and languages do matter. Some are better equipped than others, some are easier to learn than others, and some are faster to program than others. But you wouldn't know that since you never wrote a single line of code in your whole life. Idiot.volpunter said:
That's because you have no programming and database experience, so of course it doesn't mean anything to you. Using C++ or Java, OOP for processing large dataset is a poor application of OOP. Not going to explain to you why again since you have no understanding of those concepts, so it would be a pointless exercise.volpunter said:
it has everything to do with the Python thread, everytime you read something that doesn't fit your projected static imaginary world, you go into these rage. Not the first time and you did it to plenty of people here. LOL.volpunter said:
who are you again ? some kind of divine authority now ? your points deserve every criticism, and yet you can throw criticism to others but we can't on yours. Are you real, psycho ?volpunter said:
hahaha LOL typical amateur response of a clueless tard.volpunter said:
We are talking database design you dummy, not database engine store. Choosing a database engine store is not database design, you fraud. But how would you know that since you never designed professionally anything, let alone a database system or manipulation of large datasets in a programming language.volpunter said:
of course you have one, you are an angry basement boy, they all have one.volpunter said:
As mentioned, I recommend you stick with kdb's 32bit free version (I have no clue about its limitations so you may need to check whether it suits your needs because I have only used the paid commercial version where I worked before). Else, consider some of the noSQL databases that may suit your needs. If that does not look promising to you then consider writing your own binary datastore.
Important at this stage is that you understand what you actually want to query because that drives the choice of database type. I have not stored options data so I cannot add much wisdom here. If you could provide information what and how you intend to query such data then there is a better chance I or others might be able to better help. But definitely stay away from any sql solution, they are way too slow and inflexible to handle queries of such type. Queries I could imagine are like ("give me all the specific put option contracts over the past month with strikes closest to the money (atm strikes), one for each day per underlying symbol", or, "retrieve the average bid/offer spread for all atm calls over the past week"). And remember, often times it is much better to delineate storage/retrieval and custom query engines. What I mean with that is to design and implement a targeted storage and retrieval solution and when you run queries such solution would load a subset into memory and your segregated query engine will produce the desired results. That is essentially how kdb does it and a number high profile columnar data base solutions. They split the workload into different tasks that are each highly optimized. The single biggest reason why sql solutions are so slow is because the data structure/schema is not optimized for time series queries (and yours is essential a time series problem) and also because queries are run server side. It makes for lazy implementations but they almost always cannot be optimized or at least brought up to desired speed and latency.
I am out of here, I really have no patience or inclination to argue with some of the retards in this thread. PM me if you like to discuss further. I have worked with many sql solutions in the past (mostly static data), columnar databases (commercial and open source) and also have written a customized binary data storage and query solution. Good luck!
Important at this stage is that you understand what you actually want to query because that drives the choice of database type. I have not stored options data so I cannot add much wisdom here. If you could provide information what and how you intend to query such data then there is a better chance I or others might be able to better help. But definitely stay away from any sql solution, they are way too slow and inflexible to handle queries of such type. Queries I could imagine are like ("give me all the specific put option contracts over the past month with strikes closest to the money (atm strikes), one for each day per underlying symbol", or, "retrieve the average bid/offer spread for all atm calls over the past week"). And remember, often times it is much better to delineate storage/retrieval and custom query engines. What I mean with that is to design and implement a targeted storage and retrieval solution and when you run queries such solution would load a subset into memory and your segregated query engine will produce the desired results. That is essentially how kdb does it and a number high profile columnar data base solutions. They split the workload into different tasks that are each highly optimized. The single biggest reason why sql solutions are so slow is because the data structure/schema is not optimized for time series queries (and yours is essential a time series problem) and also because queries are run server side. It makes for lazy implementations but they almost always cannot be optimized or at least brought up to desired speed and latency.
I am out of here, I really have no patience or inclination to argue with some of the retards in this thread. PM me if you like to discuss further. I have worked with many sql solutions in the past (mostly static data), columnar databases (commercial and open source) and also have written a customized binary data storage and query solution. Good luck!
by the way are you by any chance this guy? Aside you, he was the only guy I came across who seems to be a die hard Python disciple, truly believing Python is the optimal language to run a algorithmic trading platform.
Welcome to ET, Mike!!!
http://www.quantstart.com/about-mike
Welcome to ET, Mike!!!
http://www.quantstart.com/about-mike
LOL !!! you do live in a wonderful imaginary world volpunter
well spoken, the python monster. Time for you to go back to text-parse and glue stuff together with Python, your language of choice, lol
I actually bet this is you, the same guy. Or you blatantly stole all his ideas and thoughts. Same exact verbiage regarding OMS through Python (I am still smirking when I think of it; which banks again ran Python OMSs? I forgot, please remind us).
I actually bet this is you, the same guy. Or you blatantly stole all his ideas and thoughts. Same exact verbiage regarding OMS through Python (I am still smirking when I think of it; which banks again ran Python OMSs? I forgot, please remind us).