November 15, 2017 at 2:15 pm
Sioban Krzywicki - Wednesday, November 15, 2017 1:25 PMThey say it is scalability and rapid development.
I believe it is because someone heard buzzwords & they don't understand the technologies involved.
They have not done any study. They know an analytics company that does great with its 8 tables. We have 900 tables.
Then you might want to introduce something that they might not understand, either. Whenever a NoSQL DB like MongoDB can ensure ACIDity, then we can talk about scalability. Unless, of course, they don't want to ensure the data is correct 100% of the time.
November 15, 2017 at 2:17 pm
Sioban Krzywicki - Wednesday, November 15, 2017 1:25 PMThey say it is scalability and rapid development.
I believe it is because someone heard buzzwords & they don't understand the technologies involved.
They have not done any study. They know an analytics company that does great with its 8 tables. We have 900 tables.
Here's a buzzword for them to try to understand "eventual consistency"
Do you want to get the same answer for the same question?
November 15, 2017 at 2:31 pm
Ed Wagner - Wednesday, November 15, 2017 1:36 PMYeah, it's free and nobody has to pay anything for it...ever. There won't be any additional costs to anyone down the line. 😉
Yup. TINSTAAFL
Sue
November 15, 2017 at 3:00 pm
Chris Harshman - Wednesday, November 15, 2017 2:17 PMSioban Krzywicki - Wednesday, November 15, 2017 1:25 PMThey say it is scalability and rapid development.
I believe it is because someone heard buzzwords & they don't understand the technologies involved.
They have not done any study. They know an analytics company that does great with its 8 tables. We have 900 tables.Here's a buzzword for them to try to understand "eventual consistency"
Do you want to get the same answer for the same question?
Deferred durability is the term I think you are looking for here. I believe SQL Server 2014 introduced that capability to SQL Server, but not sure why you would use it.
November 15, 2017 at 3:13 pm
Sue_H - Wednesday, November 15, 2017 2:31 PMEd Wagner - Wednesday, November 15, 2017 1:36 PMYeah, it's free and nobody has to pay anything for it...ever. There won't be any additional costs to anyone down the line. 😉Yup. TINSTAAFL
Sue
Do bad that the powers that be here don't understand that.
November 15, 2017 at 5:18 pm
Microsoft SQL Operations Studio (MSOS) preview is out. Gave it a quick install before I headed out. Looks very much like VSCode. Shall see what I think, but at least I can navigate objects finally! 🙂
https://docs.microsoft.com/en-us/sql/sql-operations-studio/download
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
November 15, 2017 at 9:43 pm
Sioban Krzywicki - Wednesday, November 15, 2017 1:25 PMThey say it is scalability and rapid development.
I believe it is because someone heard buzzwords & they don't understand the technologies involved.
They have not done any study. They know an analytics company that does great with its 8 tables. We have 900 tables.
Heh... I just deleted 1,500 tables from one of my smaller production databases. Those were just in the "scratch" schema. I'm getting ready to whack another 2000 from the "arch" schema and likely a couple hundred from the "dbo" schema.
I'm sure you know this but they really need to do a head to head study. I've seen too many companies make a jump "From Fat to Fire" by listening to anecdotal "proof" rather than physical proof. As the say, "One good experiment is worth a thousand expert opinions".
--Jeff Moden
Change is inevitable... Change for the better is not.
November 15, 2017 at 11:52 pm
Lynn Pettis - Wednesday, November 15, 2017 3:00 PMChris Harshman - Wednesday, November 15, 2017 2:17 PMHere's a buzzword for them to try to understand "eventual consistency"
Do you want to get the same answer for the same question?Deferred durability is the term I think you are looking for here. I believe SQL Server 2014 introduced that capability to SQL Server, but not sure why you would use it.
Deferred durability and eventual consistency are not the same thing.
Deferred durability just makes the write to the transaction log async. It's good for high-throughput where the log is a bottleneck and the chance of losing a committed transaction due to a restart is not high,
Eventual consistency (which most of the NoSQL solutions use) means that, if left for long enough after a change, all clients will see the same results for the same query. With eventual consistency, it's perfectly possible to insert a document, read the DB and not see the document you just inserted (need minimum of session-level consistency for that)
https://en.wikipedia.org/wiki/Eventual_consistency
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 16, 2017 at 12:59 am
Sioban Krzywicki - Wednesday, November 15, 2017 11:41 AMHi everyone,
It has been awhile since I posted here and I hope you're all doing well.
I have a weird situation and I was wondering about the opinion of the most knowledgeable database people I know, so I figured I'd go right to where you all are. : -)
It has been proposed that we replace a large, heavily relational database structure with Mongo.
What do you think? Personally I don't think it is workable. I'd love to know more arguments against attempting such a thing. Most of my googling finds older criticism and proponants claim the newest version doesn't have these problems.
Keeping the data structure consistent can be a problem. I've worked in places where different teams of developers, supplying the same type of data have inserted the data into MongoDB with completely different structures. This makes retrieving the data for reporting or analytical purposes very painful.
The MongoDB University has some very good, free courses. It's worth a visit to get an understanding of MongoDB.
November 16, 2017 at 7:38 am
Sioban Krzywicki - Wednesday, November 15, 2017 11:41 AMHi everyone,
It has been awhile since I posted here and I hope you're all doing well.
I have a weird situation and I was wondering about the opinion of the most knowledgeable database people I know, so I figured I'd go right to where you all are. : -)
It has been proposed that we replace a large, heavily relational database structure with Mongo.
What do you think? Personally I don't think it is workable. I'd love to know more arguments against attempting such a thing. Most of my googling finds older criticism and proponants claim the newest version doesn't have these problems.
Document stores are great for landing data and allowing your team to be lean to where the time and costs from getting data from point A to point B is going to be easier to do than a traditional data warehouse. On top of that, with the latest advancements in computing engines that work with these stores, performance massive reads on this data once it lands is going to be a lot better than your traditional data warehouse too due to the distributed nature of their design.
That being said, they don't solve all problems easy. The most difficult for me in my experience is while the data is exposed to the end user, querying it in the way the data store accepts it is a challenge compared to the familarity of the traditional RDBMS. This becomes a problem to the users actually using the data you are storing. The other issue is while extracting and loading is easy with data stores, transforming and conforming is not. Lots of code is likely needed to ensure data landed is data conformed. If you don't, then you are conforming that data on the read, which is just moving that process you normally do from the back-end to the front-end (i.e.: your business users are not modeling your data as they read it).
::sigh::
Data stores have a lot of value. Just not as the data warehouse. They are perfect for landing data before it hits the data warehouse. You cannot beat distributed processing in a sea of single machine warehousing. Have a massive query that requires a lot of indexing and optimization int he warehouse? Do it on the data store before it hits the warehouse! This is why using them also for computing that data once it lands is a great option too. But the end result, still makes sense to feed that semi-processed data into a data warehouse where it can better assist data conformity, enforce good data integrity, and of course, expose the end result in a familiar way that is accessible to all WHILE ALSO allowing you to have that raw data layer that can be exposed too.
November 16, 2017 at 7:58 am
Sioban Krzywicki - Wednesday, November 15, 2017 11:41 AMHi everyone,
It has been awhile since I posted here and I hope you're all doing well.
I have a weird situation and I was wondering about the opinion of the most knowledgeable database people I know, so I figured I'd go right to where you all are. : -)
It has been proposed that we replace a large, heavily relational database structure with Mongo.
What do you think? Personally I don't think it is workable. I'd love to know more arguments against attempting such a thing. Most of my googling finds older criticism and proponants claim the newest version doesn't have these problems.
Want to learn Mongo? This is a good opportunity
Paid by the hour? This is the sweet smell of opportunity
Your business depends on this app/db? Update your resume.
November 16, 2017 at 8:09 am
Chris Harshman - Monday, November 13, 2017 10:57 AMPhil Parkin - Monday, November 13, 2017 7:33 AMChris Harshman - Monday, November 13, 2017 10:57 AMPhil Parkin - Monday, November 13, 2017 7:33 AMSummed up by George Bernard Shaw as: "Remember: those who can, do; those who can't, teach."I think the parallel to that quote in modern times is "Those who can, do; those who can't, audit."
Summed up by George Bernard Shaw as: "Remember: those who can, do; those who can't, teach."
I think the parallel to that quote in modern times is "Those who can, do; those who can't, audit."
I'm using that one from now on. 😀
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
November 16, 2017 at 8:16 am
Jack Corbett - Thursday, November 16, 2017 8:09 AMChris Harshman - Monday, November 13, 2017 10:57 AMI think the parallel to that quote in modern times is "Those who can, do; those who can't, audit."I'm using that one from now on. 😀
I like that one, especially with the amount of auditors we have coming here; and every single one, no matter how old they look, has gone grey (and it's not just their hair!).
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
November 16, 2017 at 8:19 am
Chris Harshman - Wednesday, November 15, 2017 2:17 PMHere's a buzzword for them to try to understand "eventual consistency"
Do you want to get the same answer for the same question?
I don't really worry about this. Most of the time we create this in SQL Server when people use NoLock. Or they run reports at two different times and get different results. Eventual is usually less than a second, so if you write the system well, no issue.
November 16, 2017 at 8:19 am
Thom A - Thursday, November 16, 2017 8:16 AMJack Corbett - Thursday, November 16, 2017 8:09 AMChris Harshman - Monday, November 13, 2017 10:57 AMI think the parallel to that quote in modern times is "Those who can, do; those who can't, audit."I'm using that one from now on. 😀
I like that one, especially with the amount of auditors we have coming here; and every single one, no matter how old they look, has gone grey (and it's not just their hair!).
They're always been "grey". It just takes some time for their hair to catch up. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 60,406 through 60,420 (of 66,549 total)
You must be logged in to reply to this topic. Login to reply