在iPhone上使用SQLite的数据管理最实用的解决方案是什么？

I'm developing an iPhone application and am new to Objective-C as well as SQLite. That being said, I have been struggling w/ designing a practical data management solution that is worthy of existing. Any help would be greatly appreciated.

我正在开发一个iPhone应用程序,并且是Objective-C和SQLite的新手。话虽这么说,我一直在努力设计一个值得存在的实用数据管理解决方案。任何帮助将不胜感激。

Here's the deal:

这是交易:

The majority of the data my application interacts with is stored in five tables in the local SQLite database. Each table has a corresponding Class which handles initialization, hydration, dehydration, deletion, etc. for each object/row in the corresponding table. Whenever the application loads, it populates five NSMutableArrays (one for each type of object). In addition to a Primary Key, each object instance always has an ID attribute available, regardless of hydration state. In most cases it is a UUID which I can then easily reference.

我的应用程序与之交互的大多数数据存储在本地SQLite数据库的五个表中。每个表都有一个相应的Class,它处理相应表中每个对象/行的初始化,水化,脱水,删除等。每当应用程序加载时,它都会填充五个NSMutableArrays(每种类型的对象一个)。除了主键之外,每个对象实例始终具有可用的ID属性,而不管水合状态如何。在大多数情况下,它是一个UUID,我可以很容易地参考。

Before a few days ago, I would simply access the objects via these arrays by tracking down their UUID. I would then proceed to hydrate/dehydrate them as I needed. However, some of the objects I have also maintain their own arrays which reference other object's UUIDs. In the event that I must track down one of these "child" objects via it's UUID, it becomes a bit more difficult.

几天前,我只是通过跟踪他们的UUID来访问这些数组中的对象。然后我会根据需要进行水合/脱水。但是,我所拥有的一些对象也维护着自己的数组,这些数组引用了其他对象的UUID。如果我必须通过它的UUID跟踪其中一个“子”对象,它就会变得有点困难。

In order to avoid having to enumerate through one of the previously mentioned arrays to find a "parent" object's UUID, and then proceed to find the "child's" UUID, I added a DataController w/ a singleton instance to simplify the process.

为了避免必须枚举前面提到的一个数组以找到“父”对象的UUID,然后继续查找“子”的UUID,我添加了一个带有单例实例的DataController来简化该过程。

I had hoped that the DataController could provide a single access point to the local database and make things easier, but I'm not so certain that is the case. Basically, what I did is create multiple NSMutableDicationaries. Whenever the DataController is initialized, it enumerates through each of the previously mentioned NSMutableArrays maintained in the Application Delegate and creates a key/value pair in the corresponding dictionary, using the given object as the value and it's UUID as the key.

我曾希望DataController可以为本地数据库提供单一访问点并使事情变得更容易,但我不确定是这样的。基本上,我所做的是创建多个NSMutableDicationaries。每当初始化DataController时,它都会枚举在Application Delegate中维护的每个前面提到的NSMutableArrays,并在相应的字典中创建一个键/值对,使用给定的对象作为值,并将UUID作为键。

The DataController then exposes procedures that allow a client to call in w/ a desired object's UUID to retrieve a reference to the actual object. Whenever their is a request for an object, the DataController automatically hydrates the object in question and then returns it. I did this because I wanted to take control of hydration out of the client's hands to prevent dehydrating an object being referenced multiple times.

然后,DataController公开允许客户端使用所需对象的UUID调用以检索对实际对象的引用的过程。只要它们是对象的请求,DataController就会自动保存有问题的对象,然后返回它。我之所以这样做,是因为我希望从客户手中控制水合作用,以防止被多次引用的物体脱水。

I realize that in most cases I could just make a mutable copy of the object and then if necessary replace the original object down the road, but I wanted to avoid that scenario if at all possible. I therefore added an additional dictionary to monitor what objects are hydrated at any given time using the object's UUID as the key and a fluctuating count representing the number of hydrations w/out an offset dehydration. My goal w/ this approach was to have the DataController automatically dehydrate any object once it's "hydration retainment count" hit zero, but this could easily lead to significant memory leaks as it currently relies on the caller to later call a procedure that decreases the hydration retainment count of the object. There are obviously many cases when this is just not obvious or maybe not even easily accomplished, and if only one calling object fails to do so properly I encounter the exact opposite scenario I was trying to prevent in the first place. Ironic, huh?

我意识到在大多数情况下我只能制作一个可变的对象副本,然后在必要时替换原始对象,但我想尽可能避免这种情况。因此,我添加了一个额外的字典,用于监控在任何给定时间使用对象的UUID作为关键字对象的水合物,以及表示带有偏移脱水的水合物数量的波动计数。这个方法的目标是让DataController在“水合保留计数”达到零时自动脱水任何对象,但这很容易导致严重的内存泄漏,因为它目前依赖于调用者以后再调用减少水合作用的过程保留对象的计数。很明显很多情况下这种情况并不明显,甚至可能都不容易实现,如果只有一个调用对象无法正常完成,我会遇到与我首先想要防止的完全相反的情况。讽刺的,对吧?

Anyway, I'm thinking that if I proceed w/ this approach that it will just end badly. I'm tempted to go back to the original plan but doing so makes me want to cringe and I'm sure there is a more elegant solution floating around out there. As I said before, any advice would be greatly appreciated. Thanks in advance.

无论如何,我在想,如果我继续使用这种方法,它将会以糟糕的方式结束。我很想回到最初的计划,但这样做让我想要畏缩,我确信有更优雅的解决方案在那里漂浮。正如我之前所说,任何建议都将不胜感激。提前致谢。

3 个解决方案

#1

I'd also be aware (as I'm sure you are) that CoreData is just around the corner, and make sure you make the right choice for the future.

我也知道(我确信你是)CoreData即将到来,并确保你为未来做出正确的选择。

#2

Have you considered implementing this via the NSCoder interface? Not sure that it wouldn't be more trouble than it's worth, but if what you want is to extract all the data out into an in-memory object graph, and save it back later, that might be appropriate. If you're actually using SQL queries to limit the amount of in-memory data, then obviously, this wouldn't be the way to do it.

您是否考虑过通过NSCoder接口实现此功能?不确定它不会比它的价值更麻烦,但如果你想要的是将所有数据提取到内存中的对象图中,并在以后保存回来,那可能是合适的。如果您实际上使用SQL查询来限制内存中数据的数量,那么显然,这不是实现它的方法。

#3

I decided to go w/ Core Data after all.

毕竟我决定使用核心数据。