Tag Info

New answers tagged

2

You can't design your database that way, but you can write your queries (or rather, design your application) to handle that. The example with the LIMIT simply cannot be handled on the database because you can't change what LIMIT does fundamentally. Your example seems weird because a limit bascially means 'give me only X results'. What do you want to do if ...


0

So, first let's clearly re-state the problem in terms of its requirements: The system shall store a minimum of 4M records per day. The system shall provide a search interface to the user 2.1 The search capability shall return results in a maximum of 3s The system shall be capable of searching a minimum of 10.2 billion records The system shall use a ...


0

Thinking from the front end ... If you separate your lookup types in the UI, you might be able to have more reasonable constraints. It sounds like one lookup type is recent event-action data on an event, which allows you to isolate by time in your data search. This perhaps gives a much smaller set of data, with the likely expectation of a user that it be ...


0

Ignoring all the technical details this is an organizational/management problem and needs to be solved by the management of your organization. Your manager has to be willing to kick the problem upstairs and/or get his users to raise the problem at a high level. At your level put together or request an estimate for doing this with Oracle and Oracle ...


4

get rid of the document-based DB, its a horrible system for the kind of query you'll be doing. Go back to boring old RDBMS and you'll be a lot happier. If you do this, you can not only make reservations individually (which also help when someone adds a service to their reservation) but you can query all services assigned with a single reservation id. Simply ...


3

It is a matter of opinion. You might use postfix representation (à la RPN, or even some stack-oriented programming language), or some bytecode (specific to your expression language), or some s-expr syntax, if you want some more compact representation. JSON is probably a less compact textual representation but it is very widely used (and you've got many ...


0

I have encountered this issue several times and found the following solution at best. Please keep in mind this is my approach and your preference may be different. I always try to keep any form of SQL interaction inside the repository. Therefore the create method should be declared inside the repository. Now the issue with the ID persists. When looking at ...


2

$this->$data['id'] = $db->insertANewProduct($data); I think is a bad practice, because breaks de Single Responsibility Principle, the product class knows it's been persisted. You are loosing what you win with the repository pattern. If you want to do that another option (less OO) is Active Record. I would choose the option 1 public function ...


2

Pretty much what every other dev would do Because it's the right thing to do. what if i have 100.000 transactions With proper indexing, that's not a lot. MariaDB would have to do much more work Databases are not spreadsheets. They do not hold the entire table in memory and scan sequentially through it [often]. Most of your 100.000 ...


7

Your arguments in favor table-per-user are wrong: Every user is isolated This kind of isolation only makes sense if you create a DB user for each user and let them directly run SQL queries on your database. You usually don't do that, but instead create an API for pre-defined queries. That API should do the isolation, not some separation of ...


-2

With respect to good design, I would suggest you should use two subclasses to Users; Followers and Followed. If you draw an ER diagram, this approach is more semantically richer. So the schemas would be: User (UserName, Email, etc) FollowerUser (FollowerName, FollowerEmail, etc) FollowedUser (FollowedName, FollowedEmail, etc) Following (FollowerEmail, ...


10

I know it is better to use NoSQL for such requirements I'm not sure why you'd think that. After all, question data is very relational in nature. Here's what I'd do: User table UserId (primary key) UserName ... etc ... Following table (join table) FollowingUserId (foreign key to UserTable.UserId) FollowedUserId (foreign key to UserTable.UserId) ...


0

I think the term you're looking for is Memory-mapped file. The Neo4j devs occassionally blog about Neo4j internal, the post Neo4j Internals: Persistence and Memory Mapping should be of interest. Haven't read it myself though and I'm not sure how current it is w.r.t. to Neo4j implementation (post is from 2010), but it could be a starting point.



Top 50 recent answers are included